From nobody Mon May 6 04:54:29 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA1C1201A1; Mon, 6 May 2019 04:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 4_SiEs3Yrafz; Mon, 6 May 2019 04:54:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77815120193; Mon, 6 May 2019 04:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557143645; bh=7r0SLqUvmYiUyu0+SpFHpe+cx61PF/ZVOMn3xoXueNQ=; h=X-UI-Sender-Class:Subject:From:To:Cc:References:Date:In-Reply-To; b=dZUcR3KgAtKsZchlbZOG4dLh00N2Jvasy4Xe5p837RjBMtsAbZRC7JM0o691L/9g0 Sr7HjLOJ6zjy4ubdmcYDbB0FX7HciuW/CdMSrRMJOdscXHW/pMGEutXvsUAA7TRIin PKFTBahtybvHlqOXrcoaWkSWHpVCnEhtxQGEyN/M= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N0FxV-1gUZh42zKR-00xHTk; Mon, 06 May 2019 13:54:05 +0200 From: Julian Reschke To: Heather Flanagan Cc: "rfc-markdown@ietf.org" , "xml2rfc@ietf.org" , "xml2rfc-dev@ietf.org" References: <561D7097-7155-4DDD-8C5D-FA65663B5105@att.com> <280b0cf8-a7d0-0334-42fe-a9cd6e7966d7@gmx.de> <1DC0E053-509F-4531-9EAF-1A287FFA4ECD@att.com> <8cedc522-614c-039c-e550-8f5494ab040f@gmx.de> <308E0D17-7B84-4782-B17D-EE06EE80E6BE@rfc-editor.org> <3A0F4CD6-451F-44E2-9DA4-28235C638588@rfc-editor.org> <77365280-3339-499c-db0e-626808ff31dd@gmx.de> <2370a17d-b0e4-455e-8d9e-3d8ea13f79b6@Spark> <7663a236-9a4e-f8c3-dede-b52171dc63c9@gmx.de> Message-ID: <0d4455dd-01f8-cec4-7a0f-b372e197e90b@gmx.de> Date: Mon, 6 May 2019 13:54:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <7663a236-9a4e-f8c3-dede-b52171dc63c9@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:+b7LghVqYNxvpEttVvJG+HT+bkcEvfeV4wAAecOcsaxbBbkX4ds 3F8tbffkY0kOY0ud7xQcxAAXv2clhzT+4vaKculAlq8gjFgCHxItUw2IyWYVtGRHg/HqTzz iCmhlT3Uz4iHNfqJUQYer5iBKGMaSPg0/VJKt2hNbHY2rVR9c5DJX4dwqGXVmMY+JCW8Z6i Dde6wfEsFOlNvUu+y3y2g== X-UI-Out-Filterresults: notjunk:1;V03:K0:Q58l1u/mAsw=:dv8pFuBZg3t3wy128FDFZp 5FEKRHpBpgzv5j7kvuUzQDyRXjA+6CfpazuuCpT2RLKQElbkAB8xAnbl7XByL/iFQ/7rFW6kN pqsfv+KIPPvy0GH6iXOUNmhx7VyydOJ/0hvETjhkV8fBce80Pei8SJE6rvfsfTJRe0mHW2t1D 7IwMsMTF3Tf2Ji0+MqvAI9cPsCOF7a1s5ywC4sPjnU/wdOFfwFIK16DwlvM1aaet/VcHUlvZz cBNeOIBvGNpdRUiYCMscCgYHGn2B2djDi5z10rMMzQEvx30w/76BqCgPOL4pY3n00Q4rIRNv2 Pgqrhl7BGeXmW+OmFWijzw1W2hLIOhes3neA2B+yIMZhnLzP/o9pZ0kyEwivQHnxEi6cJBEko mggVve1WK1KjBzmsLsBSbaJV+HRyHe0sjKSvkKg6veTnhgvCy4yfl5G5+vqgYOXDYtCU50mI9 Omeyd1wW+M1RMYmuvKB+ubCT458sWqRFRyDFqpgZdsomZ41KKflSx7ms1s9zFQ1797hbsi7X3 saf/p1AObKFrjP6jdhQRpGn+McTuomUSPhIVkbfyWEe0nipKx8n6VIirv/UIiK2R7E4sXEYqW XhvNBoIDgi64+cOw9JFpnSNpamLr8ECKHHB5vf/JJhePW2JbmDL2XbxaPIel9mZvyfFWo6R5j qsVZ0BArOm+Vvc4BCao6ecSKRb3ygGaIbbfQi9uH0dbn232qmMyToXNuUOEgrCjBR7iPJs3pf /sbv4eX8fuQZMIXUbCFRBCcwJaii8cT2mV1YUoXnKh3eBwmMbyaiS8a+cfWmPXpeSavA2mKEr lXM2EK7IQaazAA92qdyT3duUu29t5nZHxlK/EByDBdzAJcn1q//dhusx+vcyF4Zr5VT3uIdse lWnTjNH+j8zAqvrkstGqZ9YFhAJV6y6Gr7NyWf8YHsh7SQc7A45JfK8EAX3/9G8sz84+eBzji 8y27VELJjJQ== Archived-At: Subject: Re: [xml2rfc-dev] [xml2rfc] [Rfc-markdown] initials handling, was: New xml2rfc release: v2.22.3 X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 11:54:21 -0000 On 22.04.2019 20:31, Julian Reschke wrote: > On 22.04.2019 16:35, Heather Flanagan wrote: >> On Apr 21, 2019, 10:23 PM -0700, Julian Reschke = , >> wrote: >>> On 11.04.2019 17:06, Heather Flanagan wrote: >>>> ... >>>> And coming back to this: >>>> >>>> A longstanding principle for referencing RFCs is to make the referenc= e >>>> match what is on the front page of the RFC itself, over what >>>> information >>>> is in any other location. This is something we should be clearer abou= t >>>> in the Style Guide, but it is a practice we=E2=80=99ve enforced for q= uite a >>>> long >>>> time. >>> >>> If you're not planning a revision anytime soon, you may want to docume= nt >>> this in detail at or fi= le >>> an erratum. >> >> I agree - I=E2=80=99ll work with the RPC on updating the web portion of= the >> style guide. >> >>> >>>> Changing the tool to match this longstanding practice is not ideal, b= ut >>>> it is expedient given that the proper way to handle this is an >>>> extensive >>>> data cleanup of the citation library. I=E2=80=99ve asked the RPC to p= rioritize >>>> getting documents published and format implementation over this kind = of >>>> data cleanup for now. >>>> ... >>> >>> I still don't get this. Is there a well-defined algorithm to decide th= e >>> detailed format? I guess so, otherwise it could not be placed into the >>> formatter. In this case, please publish it. And if there is one, just >>> get the files updated accordingly. (And yes, I volunteer, = if >>> the algorithm is clear). >>> >>> >> >> Ah, volunteering! I love that! Let me talk to Sandy and Alice to see ho= w >> best to move this forward. >> ... > > Can we start with a precise problem statement? How exactly is the rule > for initials for author names different in these ancient RFCs? Hi there once again. It would be awesome if there was a problem statement for what caused Henrik to make the change below: > * Added special initials handling for RFCs 1272 and below, to apply t= he > single initials handling enforced at that time. Could somebody please explain what the actual change in handling *is*? The style guide says in : > For one author or editor: > > [RFCXXXX] Last name, First initial., Ed. (if applicable), > "RFC Title", Sub-series number (if applicable), > RFC number, Date of publication, > . ...so just using the first initial is currently the rule as well. What *is* the change? Best regards, Julian From nobody Wed May 8 23:05:32 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16D5120189 for ; Wed, 8 May 2019 23:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com 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 qOj_BBZzTItK for ; Wed, 8 May 2019 23:03:52 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22556120125 for ; Wed, 8 May 2019 23:03:51 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id y197so1486380wmd.0 for ; Wed, 08 May 2019 23:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=XBF0ppLmPB7X8m98PF/4svhKdTCfV48z9zUkA+xRWoE=; b=VZeVsOTfJAHQEbanik4pGFVvSkgalcnfSr4C9A9ahlHp67xcO5BkDuT0MZ8WAKjgTT D/8mU5njevVG5EH5Fw1wlPC3Wy0mJ+AxtbxD5OPk2aDCixhoZsthbvB9aGrSImN7rC2H 5VMO0ClwW1GWsKMDSSBaJTcG1JtBjAjXNCIBeBJVFb6o4aVGpwaoRpQ7KUAV2WSm+TjF 8BxWq/yeaLj3mNBSDQQlVqR82L5X5W8/57hZEliZaUDAY6qo7dBtcetcR8OL5ORIL/Oc 7wcW2dfln1mbMFPrTvr4eyKrKuqHQTF5XSvd+ssc+OKd22vdarThQdIFuSpmftGOIHX5 BSTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=XBF0ppLmPB7X8m98PF/4svhKdTCfV48z9zUkA+xRWoE=; b=ZUL7dsGEUX7bkgYa8m/5OO5Y6IBiCjDniI85OPK+UyzShg/7LFeczJ4eU5ti+3+JsX 5dAGgZVTz5MIpLZhheSzD5SIPHOwJxcJmNt+aI3uUr7kbFGqyQVQqV1+BU8LedVPEeqz 6QfAeDawptOupqcZEqvODajUwLqf/MIsDmnv4eIb9wO3GrX4PAA8wnDgE3pNcFj6Kalb RgIF82xeAkq7hoY0PwQQpb6QsHfy632cchJ/2ATzRSwpeQYeikiOKbSKBzwPKSlcw8TN 23+8P4ZIMbkginPVB4xGLFDZRLWB8BW8stO8YxzGoPBbVI+NHQ1XApyIMcaHutvxkQVh oajQ== X-Gm-Message-State: APjAAAX+d6aeeitA6E4bhCNuLUi40s/KFnTXpgAR4J4hhgq3whmDjD0q aY2woOSDGlpEv3mOnvO0pkpysA== X-Google-Smtp-Source: APXvYqy8FamrDWgW/pzWxT2BKwZK8BAk+WG2tN3HQBYlcN/9nLqFMGdCpVnqQRVrZQcFqOJTckQm7w== X-Received: by 2002:a1c:f310:: with SMTP id q16mr1419779wmq.102.1557381830192; Wed, 08 May 2019 23:03:50 -0700 (PDT) Received: from miek.nl (router.mikrotime.com. [81.187.237.61]) by smtp.gmail.com with ESMTPSA id r64sm4109868wmr.0.2019.05.08.23.03.48 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 08 May 2019 23:03:49 -0700 (PDT) Date: Thu, 9 May 2019 07:03:48 +0100 From: Miek Gieben To: Julian Reschke Cc: XML Developer List Message-ID: <20190509060348.77yjfr3uuff7e67j@miek.nl> References: <20190408214850.fbwdzhza7g4omyvs@miek.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [xml2rfc-dev] docName? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 06:04:06 -0000 [ Quoting in "Re: [xml2rfc-dev] docName?..." ] >On 08.04.2019 23:48, Miek Gieben wrote: >>Hi, >> >>Compiling an xml doc with v3, gives this error: >> >>Parsing file 8341.xml >>8341.xml(3): Warning: Expected a 'docName' attribute in the >>element, but found none. >> >>Is docName now back ? > >Actually is was never gone in xml2rfc as per >. > >Note that I agree with Henrik's summary, but it sure would be cool if we >had a coherent description of what v3-as-accepted-by-xml2rfc is. So, what's the state of this? XML not having a docName are rejected: https://github.com/mmarkdown/mmark/issues/76 while the parser only emit a warning... I know need to make code changes for something that is actually not described anywhere, but seems mandatory. From nobody Thu May 9 03:17:27 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E25512011A for ; Thu, 9 May 2019 03:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SUBJ_BRKN_WORDNUMS=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TP4xetPdjnJ7 for ; Thu, 9 May 2019 03:17:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5898120100 for ; Thu, 9 May 2019 03:17:24 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:56918 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hOg78-0005T8-8i; Thu, 09 May 2019 03:17:23 -0700 To: Miek Gieben , Julian Reschke References: <20190408214850.fbwdzhza7g4omyvs@miek.nl> <20190509060348.77yjfr3uuff7e67j@miek.nl> Cc: XML Developer List From: Henrik Levkowetz Message-ID: <9f6f2abd-5cda-2611-b1e6-4e912a17f5bb@levkowetz.com> Date: Thu, 9 May 2019 12:17:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20190509060348.77yjfr3uuff7e67j@miek.nl> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4aCCppXnjdXfpPBULAXp5VtR9J8lNikRg" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de, miek@miek.nl 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 zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] docName? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 10:17:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4aCCppXnjdXfpPBULAXp5VtR9J8lNikRg Content-Type: multipart/mixed; boundary="ATPwqwLv1RWAi6Iu0ku4xWIVwGRC8tDth"; protected-headers="v1" From: Henrik Levkowetz To: Miek Gieben , Julian Reschke Cc: XML Developer List Message-ID: <9f6f2abd-5cda-2611-b1e6-4e912a17f5bb@levkowetz.com> Subject: Re: [xml2rfc-dev] docName? References: <20190408214850.fbwdzhza7g4omyvs@miek.nl> <20190509060348.77yjfr3uuff7e67j@miek.nl> In-Reply-To: <20190509060348.77yjfr3uuff7e67j@miek.nl> --ATPwqwLv1RWAi6Iu0ku4xWIVwGRC8tDth Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Miek, On 2019-05-09 08:03, Miek Gieben wrote: > [ Quoting in "Re: [xml2rfc-dev] docName?..." ] >>On 08.04.2019 23:48, Miek Gieben wrote: >>>Hi, >>> >>>Compiling an xml doc with v3, gives this error: >>> >>>Parsing file 8341.xml >>>8341.xml(3): Warning: Expected a 'docName' attribute in the >>>element, but found none. >>> >>>Is docName now back ? >> >>Actually is was never gone in xml2rfc as per >>. >> >>Note that I agree with Henrik's summary, but it sure would be cool if w= e >>had a coherent description of what v3-as-accepted-by-xml2rfc is. >=20 > So, what's the state of this? XML not having a docName are rejected: ht= tps://github.com/mmarkdown/mmark/issues/76 > while the parser only emit a warning... I'd like to know the rejection message from the datatracker. There are any number of possible rejection reasons that have nothing to do with docName, even if the description in #76 seems to indicate that it's relat= ed. I may be able to fish the rejection reason out if I know the draft name a= nd submission date. Could you provide that? I'll check the code to see if the warning should be an error, but would r= eally like to see the rejection message to understand what's up. > I know need to make code changes for something that is actually not des= cribed=20 > anywhere, but seems mandatory. You can expect that docName will continue to be needed. Regards, Henrik --ATPwqwLv1RWAi6Iu0ku4xWIVwGRC8tDth-- --4aCCppXnjdXfpPBULAXp5VtR9J8lNikRg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlzT/iMACgkQTptXS4+7 FxrPQw/9EThu5PBvW3TtrkEuLnqiAjcow2z4vVmIv1ls0g7Yb1oS2coBgFR09WhB y5KTRcKBbQktJxERVi/7ZuJRjYEwM1J+02hq3MnyUTgWL0Z54R3SOHXiD8Wu/f3T e5egEcM+OaZY44vsIAtD6aN7AHjAw+B9tqDA9bvCfqChKOtIJNT4t51HQf9XkTtv bs9pg8BgJ5krg9VYbMOV0Drb63GhqEOS3sprnmZP99WkzEBsr4JLTw0D0825LXE+ UIhVP3E9pQiUDU/+tBRFhWCAWeDAVLw+8hFVVLLpuhylHSBlOAe4frdlt/9PEDFt 1RgCeW/MSZufMXMQ51CsgDJMkKb13fPjWBiab1tp9ZLYChVanfxaEuhC9R+8IopF YvHArFhuYE/P1jUL0eUFcB8XBYZSm4C11lXiFeqWPIwnrUbrHOYspoXCt0G3gTjE PnYuOV7LbLD+qarP7LtRVd7VJvSM+3Zd2VOMluWu6xv8lEGzqW5blGxjX9VnPkwH 8M4XuTr+/zRikBGDsaWpRZEBdwbo2fKq0EN6cNMDG17ENiGUaDwwPnh7/E3ohYUO eEKevdfG2aAHVdB8H9qBtEwFEJyqG31CrkaMv0EbZoGSUZ1kpRvhKoEAVTs4sGRE M2OMzRVNZnmJh5XkrL5keVBM8mv2hOk/A6TORjrMfKWotco9uEQ= =DLN5 -----END PGP SIGNATURE----- --4aCCppXnjdXfpPBULAXp5VtR9J8lNikRg-- From nobody Thu May 9 04:25:06 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7AF12010D for ; Thu, 9 May 2019 04:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=LBzKuAJ1; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=LBzKuAJ1 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 is8pjreRYEV1 for ; Thu, 9 May 2019 04:25:03 -0700 (PDT) Received: from mail.greenbytes.de (mail.greenbytes.de [217.91.35.233]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FFC120108 for ; Thu, 9 May 2019 04:25:02 -0700 (PDT) Received: by mail.greenbytes.de (Postfix, from userid 117) id E0CF315A0CD6; Thu, 9 May 2019 13:25:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=greenbytes.de; s=mail; t=1557401100; bh=TSjVcgArzCLGLDIGBUstlkva5c4t4Gw+DgxsfXuiMcg=; h=To:From:Subject:Date:From; b=LBzKuAJ1QbIgo2VxAFhmChy2adp4ZvwKskx0CizCOJhQkUXfWIAYkal0ASSlBATwb nNwfUxOW460g330axw4fcv50oSyEjoZ7fDbBIlw4rYr//bWGL5sfCOuPELQPkNQ8En gWzrUVvarSAhdrlOdZOwii6lIvqfDXE0hm1UEIRM= Received: from [192.168.178.124] (unknown [84.171.144.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id F40D515A0526 for ; Thu, 9 May 2019 13:24:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=greenbytes.de; s=mail; t=1557401100; bh=TSjVcgArzCLGLDIGBUstlkva5c4t4Gw+DgxsfXuiMcg=; h=To:From:Subject:Date:From; b=LBzKuAJ1QbIgo2VxAFhmChy2adp4ZvwKskx0CizCOJhQkUXfWIAYkal0ASSlBATwb nNwfUxOW460g330axw4fcv50oSyEjoZ7fDbBIlw4rYr//bWGL5sfCOuPELQPkNQ8En gWzrUVvarSAhdrlOdZOwii6lIvqfDXE0hm1UEIRM= To: XML Developer List From: Julian Reschke Message-ID: Date: Thu, 9 May 2019 13:24:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 11:25:05 -0000 Hi there, see below for some feedback on , as currently described in . I have worked on an implementation in rfc2629.xslt (which should be fairly complete), and have my own set of tests at . So please read this as implementer's *practical* feedback. In general I found this change to be very disruptive, because it affects all code that deals with , and everything related to it (numbering, references, etc). A simpler approach (as proposed back then) IMHO would be far better. That said, here are the details: 1) The grammar allows to be empty This makes things really hard. How is an empty element expected to be handled? Does it contribute to the counting of paragraphs? Can it be target of an ? These things of course could be defined, but it would be much simpler to require at least one child element- 2) anchor propagation and "The first anchor on an element within an element will be promoted to the element if it has none; apart from that, anchors on elements within an element will be removed by the preptool." I understand that this is supposed to make the author's life easier - an existing element can be moved into a new container without modification. However, it causes lots of edge cases, such as: what happens if I an element that does not appear in the rendered output? I *assume* the intention is to say that the anchor propagation applies (1) not only at the preptool stage, and (2) applies *both* to the elements and all s referencing them - but the spec would need to say way more about that. 3) Invisible content Having multiple alternatives can lead to content being present in the canonical XML, but not to appear in the rendered output. I can see that this is a problem with textual fallback content already, but allowing any number of altenative elements in the canonical XML makes this a much more serious problem. 4) Processing model "This would let the renderer pick the most appropriate instance for its format from the alternatives present within an element, based on the "type" attribute of each enclosed element.If more than one element is found within an element, with the same "type" attribute, the renderer could select the first one, or possibly choose between the alternative instances based on the output format and some quality of the alternative instances that made one more suitable than the other for that particular format, such as size, aspect ratio, or whatnot." "Implementation: Xml2rfc as of version 2.19.0 implements this, with a preference list when rendering to HTML and PDF of ( "svg", "binary-art", "ascii-art" ), while the text renderer uses the list ( "ascii-art", ) -- i.e., one entry only." So there is no precise processing model, due to the fact that we can't predict what kind of alternative formats will come up. The description of the *actual* model is specific to a certain version of one implementation. In addition, this depends on the "type" attribute which as per RFC 7991 is sort of advisory only (see ). I believe it would be better (and more author friendly) to actually inspect the contents of the , and decide based on that (that's what I'm currently doing in rfc2629.xslt). I have spent a significant amount of time to implement this, but I'd still prefer to throw this all away and make a less-intrusive extension instead. That being said, point 3) above really needs to be discussed in the context of how the canonical form and the default rendering relate to each other. Best regards, Julian From nobody Thu May 9 04:58:00 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72606120020 for ; Thu, 9 May 2019 04:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKjxnJahoY7A for ; Thu, 9 May 2019 04:57:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CDFE120006 for ; Thu, 9 May 2019 04:57:56 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:57702 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hOhgQ-0004wr-Um; Thu, 09 May 2019 04:57:55 -0700 To: Julian Reschke , XML Developer List References: From: Henrik Levkowetz Message-ID: Date: Thu, 9 May 2019 13:57:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8oiJWOGsDKEMxguHVPQJpAtPqE6i09n6T" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@greenbytes.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 11:57:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8oiJWOGsDKEMxguHVPQJpAtPqE6i09n6T Content-Type: multipart/mixed; boundary="3NjohsowcG3CO9MELMO5aS5eqbUIWjVXJ"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , XML Developer List Message-ID: Subject: Re: [xml2rfc-dev] feedback References: In-Reply-To: --3NjohsowcG3CO9MELMO5aS5eqbUIWjVXJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2019-05-09 13:24, Julian Reschke wrote: > Hi there, >=20 > see below for some feedback on , as currently described in=20 > . >=20 > I have worked on an implementation in rfc2629.xslt (which should be=20 > fairly complete), and have my own set of tests at=20 > . So=20 > please read this as implementer's *practical* feedback. >=20 > In general I found this change to be very disruptive, because it affect= s=20 > all code that deals with , and everything related to it=20 > (numbering, references, etc). A simpler approach (as proposed back then= )=20 > IMHO would be far better. >=20 > That said, here are the details: >=20 >=20 > 1) The grammar allows to be empty >=20 > This makes things really hard. How is an empty element expecte= d=20 > to be handled? Does it contribute to the counting of paragraphs? Can it= =20 > be target of an ? These things of course could be defined, but it= =20 > would be much simpler to require at least one child element- Good point. What would be your proposed grammar change to address this? > 2) anchor propagation and >=20 > "The first anchor on an element within an element=20 > will be promoted to the element if it has none; apart from=20 > that, anchors on elements within an element will be = > removed by the preptool." >=20 > I understand that this is supposed to make the author's life easier - a= n=20 > existing element can be moved into a new container=20 > without modification. >=20 > However, it causes lots of edge cases, such as: what happens if I =20 > an element that does not appear in the rendered output? I=20 > *assume* the intention is to say that the anchor propagation applies (1= )=20 > not only at the preptool stage, and (2) applies *both* to the = =20 > elements and all s referencing them - but the spec would need to = > say way more about that. Ok. > 3) Invisible content >=20 > Having multiple alternatives can lead to content being presen= t=20 > in the canonical XML, but not to appear in the rendered output. I can=20 > see that this is a problem with textual fallback content already, but=20 > allowing any number of altenative elements in the canonical=20 > XML makes this a much more serious problem. I don't see this -- the essential problem is the same whether the number of alternatives are 2 or more than 2. And that is built into the idea that the XML should be able to provide richer content for HTML than for text; I don't see any way around this. > 4) Processing model >=20 > "This would let the renderer pick the most appropriate =20 > instance for its format from the alternatives present within an =20 > element, based on the "type" attribute of each enclosed =20 > element.If more than one element is found within an = > element, with the same "type" attribute, the renderer could select the = > first one, or possibly choose between the alternative instances based o= n=20 > the output format and some quality of the alternative instances that=20 > made one more suitable than the other for that particular format, such = > as size, aspect ratio, or whatnot." >=20 > "Implementation: Xml2rfc as of version 2.19.0 implements this, with a = > preference list when rendering to HTML and PDF of ( "svg", "binary-art"= ,=20 > "ascii-art" ), while the text renderer uses the list > ( "ascii-art", ) -- i.e., one entry only." >=20 > So there is no precise processing model, due to the fact that we can't = > predict what kind of alternative formats will come up. The description = > of the *actual* model is specific to a certain version of one=20 > implementation. The serious fussiness here comes from=20 1) not prescribing whether the first or some other should be chosen when there are multiple instances with the same type. For this, I propose that we codify that the first is always chosen, or alternatively, make it an error to have more than one of each typ= e. 2) having implementation-specific preference lists. We could codify th= is more strictly too. Would the xml2rfc settings work for you here? > In addition, this depends on the "type" attribute which as per RFC 7991= =20 > is sort of advisory only (see=20 > ). >=20 > I believe it would be better (and more author friendly) to actually=20 > inspect the contents of the , and decide based on that (that's= =20 > what I'm currently doing in rfc2629.xslt). We've had this discussion before, and disagree. I maintain that an expli= cit type is better than an implicit type. An implicit type leads to _huge_ difficulties in specifying exactly how the inspection is done and how the result is interpreted. > I have spent a significant amount of time to implement this, but I'd=20 > still prefer to throw this all away and make a less-intrusive extension= =20 > instead. >=20 > That being said, point 3) above really needs to be discussed in the=20 > context of how the canonical form and the default rendering relate to=20 > each other. And that's the issue that is inherent also in the RFC 7991 schema, since = it permits 2 different artworks, only one of which will be shown in the rendered form. Nothing new here. I'm fine with discussing the issue, bu= t don't make it out as something introduced with . Regards, Henrik --3NjohsowcG3CO9MELMO5aS5eqbUIWjVXJ-- --8oiJWOGsDKEMxguHVPQJpAtPqE6i09n6T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlzUFbsACgkQTptXS4+7 FxoJ4hAA00jGv80yPTvdeDRvZyrkJm3/kzwGU9289X6a7/O3LmqWPY8Yk2AnLpoX TafI2EXUGswlhmmkLBLWF98rIuci9MsedkXjLzBMrn+goI/LUe2d/xv6qqL6sZ2P IobKFGFVb9qE/VxA+gDe8j7Sh9Pn5mUrrAYGA6boks+UCewcQ+9FDY2/YhWMwAw/ QMFIgD7RQUbjqHaRBPKKQoYMWMH2is0mECTTYzdtP5fTxAeuv+BZ5J5ccLM8rhnL hHVqlVguxAcm6PLrxCHX6bW5F87zRlvYTSRMoDWMYLcqTaLLsahAOev+VbTlpwlM Igx7tfaRHrwbEr7VNoUvlEp2ICIsKPoEidug6o6BcJzbzBG5ELoiG76/KgdVKO+T OhQ9wbb0gJ/S/oUtVOiXJ3ZiGkhy+0BFU/CFQiBcnuuakBfW23o8gvxXW8mPlfaC xYiE9eJcQUspQyMqc+Pvyycu7p5mvfIjH9L8KTP6b+iSkE1K1RV2i23YH23mMcLz hCVs6F7p2+NPmeV0fWuhEJZhnk+1+UusKwLgY9TlHs2nPB3mrWJUVvwTmbPpdNR6 LFXd352SPo/sErV1Y9EJTEMLZH7YXRO7Xel5opfGncw4lHoqhpsJ2EiIabemuzQd wCQv9QNalWGlTiWrrfWTGsffaRmE2DUBgEWaDa2rmfBpt6IOFkc= =/8bo -----END PGP SIGNATURE----- --8oiJWOGsDKEMxguHVPQJpAtPqE6i09n6T-- From nobody Thu May 9 05:11:07 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394BF12001E for ; Thu, 9 May 2019 05:11:06 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 n3KtQQdpkshW for ; Thu, 9 May 2019 05:11:03 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66BF2120006 for ; Thu, 9 May 2019 05:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557403846; bh=VaTlDjVl3IhjDFXbI4I73q8VuuSmwaptauyu2zRu4CM=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=dIc1WIbpIFrD3dAmZChHqRE/yvft7sItZFN8dosXFlG+hX6dsxw46TqKrw2ImX7JO Wd6YoYagmUeVg3WZsUUvo82Cki0hJ0H0LxpWx3ypQopkV03EjhS/Q9lKhAZx4thvjp AZcXpVZlqNVvx9NRvv8LQyt2Alip7x3YfJ+0Nf8M= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.144.58]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LwrPM-1geix42UEi-016NjF; Thu, 09 May 2019 14:10:46 +0200 To: Henrik Levkowetz , XML Developer List References: From: Julian Reschke Message-ID: Date: Thu, 9 May 2019 14:10:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:4nCw+PNAuEAxfV1DjARMz7bcVs+I7KwChusu4KO4iBJm7bNb1VV YPT6y/0EZf1JNT3e6rRgceBBlJwsxmo/xE3aJtg3V+qC+0TnrZ5TPmPEJH5w93YBfGnmfen 9CkJZrGwkb0UyCnvtkxVfZP1XYGyqen89wvIqQLTcUN9lCPDqlZ1RNdxEX0hCZyPDgicE3/ G1sq5vRECgWoLCV424Bqw== X-UI-Out-Filterresults: notjunk:1;V03:K0:9TkhwuHjyH4=:4JgB80ctsNH1D+oarS4DKf 5CCo2Y00L5YxxN3lWomTbcUrwwU/BfLvxFWrsEINEiIjzR+1d7eznZ+QS6o5TFtPBczrCqOaa W8r1SiRMDDJuqZMRIdzelgisGsi4fBHjgg87Uq28BzcUiamle1jPs7ImgX+WX5hcHSfLqQjwl 5vwaidKs0+7nsDptcbW/hNg+jpfdukbOmc82N6sDtba8IpO9fFPfLZFfGEK6UyHAhjlzIebFO eiZUq6pu6CY9REUnoEvipzoUlTsMVPPnGgSBHjnIA1JHt/lirdatUUBK77n7ZLU/oX/EHVVCR RHDPal71gax44ux5zclwz8pZ2+oFvyyAO6gtyCU5EdZRWmB8Zxye9EqYqumYKU0dKkitM9YXZ ow2fez3ma6WxagcD9Kd+6Du/JSn3cF55dISQm9xegs83V96dcQoBVLI7NO7TjnyVmppP2jadG 8LuTmCBzIV9pYWM/taAT9dsfCtG2nWTbpCoJ/ZchMBy9ItfVX1mYhcfTxsbLcRFPRjMjTi7Zk lVHfNkKx8dlLlVlkaOJLkgCT4V/OdwJfzUt0GEEPWSj1hdJHH/FQ3OrkfrsED57+B8F5SM1u0 rcYN/fJnOSANn/BJ5FGhfVV2qMOjghWgNfRoPR+1jFDxomAlM3/dmNrbEleJbffDm9XcYj3sq x6BuWhG9zBFDVARnaRj1FoeIvzkO8GJ+/VK58Qvf6guEC+9NdBYIKVVGQc7aRNTHZYNNpzS1C M4ViM50reU0vHAmVHWqHAQQPiZCp5iN8jn92ClyFYHnz/MfGtuBIkCFm8aBRgTfIuMOhtZpbL rrZny5i0jDrbryMgEyVitBFJVCsN/n6wlmY8mcpyxp9aVztKDBPWhs2hPARdxi35KmNAA4oQu No0BMLtRieISGvnPF3EFs9Z4NcCBjGO62frE8gU7kOrv1sfGFp/1JKR5o4kfPJU3vJk6OkdNl BuighMLtHSw== Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 12:11:06 -0000 On 09.05.2019 13:57, Henrik Levkowetz wrote: > Hi Julian, > > On 2019-05-09 13:24, Julian Reschke wrote: >> Hi there, >> >> see below for some feedback on , as currently described in >> . >> >> I have worked on an implementation in rfc2629.xslt (which should be >> fairly complete), and have my own set of tests at >> . So >> please read this as implementer's *practical* feedback. >> >> In general I found this change to be very disruptive, because it affect= s >> all code that deals with , and everything related to it >> (numbering, references, etc). A simpler approach (as proposed back then= ) >> IMHO would be far better. >> >> That said, here are the details: >> >> >> 1) The grammar allows to be empty >> >> This makes things really hard. How is an empty element expecte= d >> to be handled? Does it contribute to the counting of paragraphs? Can it >> be target of an ? These things of course could be defined, but it >> would be much simpler to require at least one child element- > > Good point. What would be your proposed grammar change to address this? artset =3D element artset { attribute xml:base { text }?, attribute xml:lang { text }?, attribute anchor { xsd:ID }?, attribute pn { xsd:ID }?, artwork+ } (I think) >> 2) anchor propagation and >> >> "The first anchor on an element within an element >> will be promoted to the element if it has none; apart from >> that, anchors on elements within an element will be >> removed by the preptool." >> >> I understand that this is supposed to make the author's life easier - a= n >> existing element can be moved into a new container >> without modification. >> >> However, it causes lots of edge cases, such as: what happens if I >> an element that does not appear in the rendered output? I >> *assume* the intention is to say that the anchor propagation applies (1= ) >> not only at the preptool stage, and (2) applies *both* to the >> elements and all s referencing them - but the spec would need to >> say way more about that. > > Ok. > >> 3) Invisible content >> >> Having multiple alternatives can lead to content being presen= t >> in the canonical XML, but not to appear in the rendered output. I can >> see that this is a problem with textual fallback content already, but >> allowing any number of altenative elements in the canonical >> XML makes this a much more serious problem. > > I don't see this -- the essential problem is the same whether the number > of alternatives are 2 or more than 2. And that is built into the idea > that the XML should be able to provide richer content for HTML than for > text; I don't see any way around this. If we just have "rich" and "text fallback", we can always capture that in HTML too (3D"..." etc). It might not be visible by default, but it would at least be included. >> 4) Processing model >> >> "This would let the renderer pick the most appropriate >> instance for its format from the alternatives present within an >> element, based on the "type" attribute of each enclosed >> element.If more than one element is found within an >> element, with the same "type" attribute, the renderer could select the >> first one, or possibly choose between the alternative instances based o= n >> the output format and some quality of the alternative instances that >> made one more suitable than the other for that particular format, such >> as size, aspect ratio, or whatnot." >> >> "Implementation: Xml2rfc as of version 2.19.0 implements this, with a >> preference list when rendering to HTML and PDF of ( "svg", "binary-art"= , >> "ascii-art" ), while the text renderer uses the list >> ( "ascii-art", ) -- i.e., one entry only." >> >> So there is no precise processing model, due to the fact that we can't >> predict what kind of alternative formats will come up. The description >> of the *actual* model is specific to a certain version of one >> implementation. > > The serious fussiness here comes from > > 1) not prescribing whether the first or some other should b= e > chosen when there are multiple instances with the same type. > For this, I propose that we codify that the first is always chosen= , > or alternatively, make it an error to have more than one of each t= ype. +1 to always pick the first. > 2) having implementation-specific preference lists. We could codify = this > more strictly too. Would the xml2rfc settings work for you here? > >> In addition, this depends on the "type" attribute which as per RFC 7991 >> is sort of advisory only (see >> ). >> >> I believe it would be better (and more author friendly) to actually >> inspect the contents of the , and decide based on that (that's >> what I'm currently doing in rfc2629.xslt). > > We've had this discussion before, and disagree. I maintain that an expl= icit > type is better than an implicit type. An implicit type leads to _huge_ > difficulties in specifying exactly how the inspection is done and how > the result is interpreted. Let me disagree. The only case relevant for RFCs right now is SVG, and that can be detected very easily be the processor without the presence of a type attribute. >> I have spent a significant amount of time to implement this, but I'd >> still prefer to throw this all away and make a less-intrusive extension >> instead. >> >> That being said, point 3) above really needs to be discussed in the >> context of how the canonical form and the default rendering relate to >> each other. > > And that's the issue that is inherent also in the RFC 7991 schema, since= it > permits 2 different artworks, only one of which will be shown in the > rendered form. Nothing new here. I'm fine with discussing the issue, b= ut > don't make it out as something introduced with . I believe it's much worse then before, thus I want to make sure people are aware of it. Best regards, Julian From nobody Thu May 9 23:51:55 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668A5120169 for ; Thu, 9 May 2019 23:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 Ytih5vtDjbuH for ; Thu, 9 May 2019 23:51:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15DB12017F for ; Thu, 9 May 2019 23:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557471093; bh=Ost7WsNe3OjLRDf6WPTP8APdjmjQLZ+hq8VdrDOFv4g=; h=X-UI-Sender-Class:Subject:From:To:References:Date:In-Reply-To; b=N7isQK5Dwmo44m93uf7YLvVi3Mn2GPhP6wvAWFEaIg/1zF4xm6ZYzqJ3k3eV1WRCN FbaqBXhav1blzftnEoBTEBZZZXrLf0Su8brNgZMhnNHfJDynXiDnb4pttzLgvsjT3V wxmPJIXKdeYPj1dZNUYwtsWxFiS6gSBVcLoCIjIc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.148.236]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lu8Ri-1ggfyt35SY-011Q3l; Fri, 10 May 2019 08:51:33 +0200 From: Julian Reschke To: Henrik Levkowetz , XML Developer List References: Message-ID: Date: Fri, 10 May 2019 08:51:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:s8N7x4dWxvpNn3MH6w3bIlRSlBwxC5ZbjpAarvglbzobsm280+B N7FosTuFYTBCMleyO1uVCb3EtdsRP6pozFTk5e/PORhuQlHN97Iy+Ruy8k8iKiwR27LIrzo tUzlETlnfFx/1jpSlwwUrhmMP9WmAxDyHWHVjMN9qKtAwu7ifJZGrljkAhXLES5agBsL52I 68pRWSHMaG5RID6OzL1Jg== X-UI-Out-Filterresults: notjunk:1;V03:K0:ORHeS0GMmeA=:bZN/FryAyMErt8NwQwi7bA jOWrfRLFHiWw6LiGhIDvrWCZOHUBMYGKGfx5PbatTx4VrCRtCaak5f6OZul8rnHWQLRSxLcQk CfnD+jYC/7Gcnnw3/U4VvWMYQilQd/MsmVzGJjyZe8PaFx7TK8MSPI7ogwm7qxZt+yQziBvHY tKRa+ugWJfOpcB1LOxJF8DzvJuq1QEgTILosmkkf+mCwgFVgGdswzUzTozDqhsIPmerfjwQZV /jBqGp78R52AZ8KyhOxEVJbrAtO40v9fMjoG/+fZbeqMS5YG0VKfdVv6bg4+XiUKlSyNf8KFc EPCm76ve2uZvV2BCGEo4whfQamzvkgua5Cau9hUciIyhMk71B8fnYOo3qG/MJRB/doz+tZ3dA mYtineYqEuJVqDUaEZMcdGgAwvc8l13+ltBceQgyQjMz/ciB74onfqygwXO9ivao20d5qnG16 nPEIbMeExbvagIlsFqEWwffQd2/vAHvya/Jc8YiQfGIOmR0EFL1kBzy/1yZ9zvthtxXlfEEgD EeJTDUCKYwU/AlfOIab2+y5Ee1jFoKRjGY9XxNxZ63DFm8JIMdIIqfwcxjjZEhk2RRrkstfLh NvwywPCk5yHdZBJEUFU/L8V4q19oo2fEZPvgt9wF3Ch7p605Ufn/lUYcMeRn6KA0zj5Tag7Kf MET6W1Pta+qzBMOkm8xVJxMy/VktJbfE42mFQJgmOdZQ6qE2Zp9Uy/AdGcI0NnF56wFsnYFS3 O8hVU4TSGOO9duwyG0tk1yVA/n6Q48Jrsq+wXc4X8PxauOZCUk7S6jj9nnlfmE/fjXMdOSK6Y hQaUDUslMaplAkwEZUUigFirNCuEqDIPOkKz5EXw9PGeZVAUA3MDZ9K4BfjtnkX/Az0xWRwin oq6gMwRy6JzJqoBpCxIj5i1ql+COL0mUk0lA3MrZrDFXvWsc2tDQ6nsPrzQxvJO6pdK1X1iRk CsjYelM1oiw== Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 06:51:54 -0000 On 09.05.2019 14:10, Julian Reschke wrote: > On 09.05.2019 13:57, Henrik Levkowetz wrote: >> Hi Julian, >> >> On 2019-05-09 13:24, Julian Reschke wrote: >>> Hi there, >>> >>> see below for some feedback on , as currently described in >>> . >>> >>> >>> I have worked on an implementation in rfc2629.xslt (which should be >>> fairly complete), and have my own set of tests at >>> . So >>> please read this as implementer's *practical* feedback. >>> >>> In general I found this change to be very disruptive, because it affec= ts >>> all code that deals with , and everything related to it >>> (numbering, references, etc). A simpler approach (as proposed back the= n) >>> IMHO would be far better. >>> >>> That said, here are the details: >>> >>> >>> 1) The grammar allows to be empty >>> >>> This makes things really hard. How is an empty element expect= ed >>> to be handled? Does it contribute to the counting of paragraphs? Can i= t >>> be target of an ? These things of course could be defined, but i= t >>> would be much simpler to require at least one child element- >> >> Good point.=C2=A0 What would be your proposed grammar change to address= this? > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 artset =3D > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 element artset { > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attribute xml:ba= se { text }?, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attribute xml:la= ng { text }?, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attribute anchor= { xsd:ID }?, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attribute pn { x= sd:ID }?, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 artwork+ > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } > > (I think) > >>> 2) anchor propagation and >>> >>> "The first anchor on an element within an element >>> will be promoted to the element if it has none; apart from >>> that, anchors on elements within an element will be >>> removed by the preptool." >>> >>> I understand that this is supposed to make the author's life easier - = an >>> existing element can be moved into a new container >>> without modification. >>> >>> However, it causes lots of edge cases, such as: what happens if I >>> an element that does not appear in the rendered output? I >>> *assume* the intention is to say that the anchor propagation applies (= 1) >>> not only at the preptool stage, and (2) applies *both* to the >>> elements and all s referencing them - but the spec would need to >>> say way more about that. >> >> Ok. >> >>> 3) Invisible content >>> >>> Having multiple alternatives can lead to content being prese= nt >>> in the canonical XML, but not to appear in the rendered output. I can >>> see that this is a problem with textual fallback content already, but >>> allowing any number of altenative elements in the canonical >>> XML makes this a much more serious problem. >> >> I don't see this -- the essential problem is the same whether the numbe= r >> of alternatives are 2 or more than 2.=C2=A0 And that is built into the = idea >> that the XML should be able to provide richer content for HTML than for >> text; I don't see any way around this. > > If we just have "rich" and "text fallback", we can always capture that > in HTML too (3D"..." etc). It might not be visible by default, > but it would at least be included. > >>> 4) Processing model >>> >>> "This would let the renderer pick the most appropriate >>> instance for its format from the alternatives present within an >>> element, based on the "type" attribute of each enclosed >>> element.If more than one element is found within an >>> element, with the same "type" attribute, the renderer could select the >>> first one, or possibly choose between the alternative instances based = on >>> the output format and some quality of the alternative instances that >>> made one more suitable than the other for that particular format, such >>> as size, aspect ratio, or whatnot." >>> >>> "Implementation:=C2=A0 Xml2rfc as of version 2.19.0 implements this, w= ith a >>> preference list when rendering to HTML and PDF of ( "svg", "binary-art= ", >>> "ascii-art" ), while the text renderer uses the list >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ( "ascii-art", ) -- i.e., o= ne entry only." >>> >>> So there is no precise processing model, due to the fact that we can't >>> predict what kind of alternative formats will come up. The description >>> of the *actual* model is specific to a certain version of one >>> implementation. >> >> The serious fussiness here comes from >> >> =C2=A0=C2=A0 1) not prescribing whether the first or some other should be >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 chosen when there are multiple instances= with the same type. >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For this, I propose that we codify that = the first is always chosen, >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or alternatively, make it an error to ha= ve more than one of each >> type. > > +1 to always pick the first. > ... (if there is a type attribute) Best regards, Julian From nobody Thu May 9 23:54:35 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CDD120184 for ; Thu, 9 May 2019 23:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com 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 N1Ffk1Pb16mu for ; Thu, 9 May 2019 23:54:32 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19242120178 for ; Thu, 9 May 2019 23:54:32 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id s15so6291808wra.12 for ; Thu, 09 May 2019 23:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=wK100cHOZALgCMoCpGsa0vmF03WkVyDWUx+egKBbFtQ=; b=0th+PEtBKHySe+UZBhptpLTGRELWchxKMR2KaKiWoa4smNrXTaJ3rmbd8CGBESBaWH M4ZpmtN6YGr98Mx8ZN//ZgDxUIySnag08TAl/gbsQSZQ3NJAaq0eW7NtTISrgF1QXyvI unO6KQmZHXMaiPlhbX/a6S6lFQpeAln1vwrhlN9gbM8yUxLiZfD9qFRiH7+SoiAw4cH2 3adK8okhUL/ivg8Dnubtz//V3uwSVi//uttaavCVbcEKa07nQQVfFQrZDCiYg6lVhC3f 7BI7r472kbikiWQAC0oAjeR/v7eFyagH9e9j77Hphn7H4gZI0H45poKr/I3xFnzV1wKP HfYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wK100cHOZALgCMoCpGsa0vmF03WkVyDWUx+egKBbFtQ=; b=SkzzwSsQbxRqbp/XPHgTZs+JAfgSGAY2b+qukLyoWUqCu8Oba+vzh1sY3O5fpMIhSg UHh3Ze6Tm/qcRNUk/perP6C59OwRrUqUD+H7hOqjUHeXqbFyiKMfyWvmVrj/PyzBJQJl k3hf6j5OLPbcukrziZTOvJsoHnXFd+JWCa1/Hdr+S/5ZWW/69MHIiAxrVRqH5JJoY68r YswziD2iFCgzDS8jRiwGAcR0Xrxxpr2Lxf1R9SnshgZvNBl5r3hgqAU3tVhmliUx/3Yu OrsJq9TZIq9jbE/b6fScdoi8chG0KVf1+ORNSyBDINNkeIy1ZrkIDFdiTf/aExddqY39 Mopw== X-Gm-Message-State: APjAAAWK7hvxiLGZXucA+1NQ5VgF3C/SSpfP8sDZXzi/E+78bf70xv9X 0dNs75cWtVIjeKvd/7dYfMEiCQ== X-Google-Smtp-Source: APXvYqzLtFGhbun/yIno+m/bbradzHeR+EGbMFdBnlLry9R1jLb/NeYTzNNrhSQo+chil9ZiDBZdfQ== X-Received: by 2002:a5d:4907:: with SMTP id x7mr1264076wrq.199.1557471270630; Thu, 09 May 2019 23:54:30 -0700 (PDT) Received: from miek.nl (router.mikrotime.com. [81.187.237.61]) by smtp.gmail.com with ESMTPSA id r2sm9021165wrr.65.2019.05.09.23.54.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 09 May 2019 23:54:29 -0700 (PDT) Date: Fri, 10 May 2019 07:54:25 +0100 From: Miek Gieben To: Henrik Levkowetz Cc: Julian Reschke , XML Developer List Message-ID: <20190510065425.iy74lntsbeeakjeg@miek.nl> References: <20190408214850.fbwdzhza7g4omyvs@miek.nl> <20190509060348.77yjfr3uuff7e67j@miek.nl> <9f6f2abd-5cda-2611-b1e6-4e912a17f5bb@levkowetz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <9f6f2abd-5cda-2611-b1e6-4e912a17f5bb@levkowetz.com> Archived-At: Subject: Re: [xml2rfc-dev] docName? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 06:54:34 -0000 [ Quoting in "Re: [xml2rfc-dev] docName?..." ] >I'd like to know the rejection message from the datatracker. There are >any number of possible rejection reasons that have nothing to do with >docName, even if the description in #76 seems to indicate that it's related. > >I may be able to fish the rejection reason out if I know the draft name and >submission date. Could you provide that? I've asked on the issue. Thanks! >> I know need to make code changes for something that is actually not described >> anywhere, but seems mandatory. > >You can expect that docName will continue to be needed. Ok, is this always seriesInfo.value ? https://tools.ietf.org/html/rfc7991#section-2.47.6 Esp considering this changes from filename for an I-D to a number when the document becomes an RFC? Also because there is a number attribute (https://tools.ietf.org/html/rfc7991#section-2.45.7), which I added eons ago because xml2rfc complained; maybe that can be removed now (because its deprecated) ? /Miek -- Miek Gieben From nobody Thu May 9 23:58:52 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6FC12018B for ; Thu, 9 May 2019 23:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com 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 xuAZpvKauEBc for ; Thu, 9 May 2019 23:58:49 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99928120181 for ; Thu, 9 May 2019 23:58:49 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id r4so6312852wro.10 for ; Thu, 09 May 2019 23:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=01JuZk1b23ggKQO/ICZX49FcwROK3VMKpQOMhtPHLe0=; b=Htke/a7Z+0+TigHp61bidTi6wNuxvLgMC6VC6gNfV18llPNYetHQTB5arpmIWdpNYL JpropwhCxczuChcBX8qpwmHE1/O2RsnBC5ywKvf5dYw21kgKtdjFGxmAN2cmyGV8IqsG E431XamnlxgOvuICSOJ1o2h23e91XUNBFA2G5+RlleC9hr9T7c/eB+Ht1GVhx8WFPgOV bzCMJPEAhuWWGwPtGf4n6/wHAslNpKMKoXbAN5PNBUJ4aHUpRgCyNqm2fOYx3lZkdWh6 IfqIwtfgnuA77cqciQeCVqkrNtui9//HR69Z0uGJwF1gygEw0bPXADCnozJCE+1zqA4H 3sOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=01JuZk1b23ggKQO/ICZX49FcwROK3VMKpQOMhtPHLe0=; b=mErkr1SID27e4ZjxbcDVWaHevsrFLf1P4k7J0xOGzSV0I0mBc5BRzWTaOjdPGDjN4m ZwoV2Y9kIR+1IMpiDNGUf1uhnYX4dsg1KUf+QuJOCj0hFaYZi0U4MJ3VDX1ZBGVVDkMe aGVzM4cUAJMzfHgvm69vCo3Kx4H+XvXQL9x/1kV1fWJHz4T5zDQlfTDspVnvu4zJkaAi Ikm1XbnsWIgJdIL8mpVFOWVbk9HZAiUmLtOnad+7E5oyFLInqhPlHswjJtmAtrwWNQ7E iiBK/kAV21dV736ZLKqcPn4fLRhQCAB3u2TUm4AmC5COfNzZLcBiaiOz4qqc0TRvVxfs qiEA== X-Gm-Message-State: APjAAAUF7TCQj0IvUq26UasuYxU3MOwnMvMLQftIAbEqV+jUj8UqfGq3 Uo2qk25TUEfMKanVdM7+ZmmM2A== X-Google-Smtp-Source: APXvYqxeHJ+DoNC4yaBVmiarZFnUxOCBFMPP02D1IzUeJdBgIOlsFw2jl8JYrxtnbLnH7WTF1CY67A== X-Received: by 2002:adf:eb50:: with SMTP id u16mr6692962wrn.54.1557471528207; Thu, 09 May 2019 23:58:48 -0700 (PDT) Received: from miek.nl (router.mikrotime.com. [81.187.237.61]) by smtp.gmail.com with ESMTPSA id x64sm1894557wmg.17.2019.05.09.23.58.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 09 May 2019 23:58:47 -0700 (PDT) Date: Fri, 10 May 2019 07:58:44 +0100 From: Miek Gieben To: Henrik Levkowetz Cc: Julian Reschke , XML Developer List Message-ID: <20190510065844.pzrzi26lieeomneb@miek.nl> References: <20190408214850.fbwdzhza7g4omyvs@miek.nl> <20190509060348.77yjfr3uuff7e67j@miek.nl> <9f6f2abd-5cda-2611-b1e6-4e912a17f5bb@levkowetz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <9f6f2abd-5cda-2611-b1e6-4e912a17f5bb@levkowetz.com> Archived-At: Subject: Re: [xml2rfc-dev] docName? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 06:58:51 -0000 code to deal with the number attribue: https://github.com/mmarkdown/mmark/blob/master/render/xml/title.go#L50 Have to re-check to see if that is still true. From nobody Fri May 10 00:23:09 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160F2120178 for ; Fri, 10 May 2019 00:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 0tzdf4v6Z6WD for ; Fri, 10 May 2019 00:23:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A457D120177 for ; Fri, 10 May 2019 00:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557472963; bh=fHT0StkqezAMYLct6YLwBB7lB18yV5VZaoowdEm7XDQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ARRwO894EPQQilKxLfkbTqDCQwUQ5PFPJXZBWOJtAKk3Iq+8vuS3Wjw3yb6jOzVnB Mst7Uz+uvJq3Fji8+oh11IoIVeCvrqoUI4Wyx0Bj7dL5aDMdr7aostXFi2Oiypjcdv JgE9Ty1faB7xVyG3tH+94TSXpV2hwxrzwEyjrP6Q= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.148.236]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MS5QA-1hIzJR1yQs-00TDDq; Fri, 10 May 2019 09:22:43 +0200 To: Miek Gieben , Henrik Levkowetz Cc: XML Developer List References: <20190408214850.fbwdzhza7g4omyvs@miek.nl> <20190509060348.77yjfr3uuff7e67j@miek.nl> <9f6f2abd-5cda-2611-b1e6-4e912a17f5bb@levkowetz.com> <20190510065425.iy74lntsbeeakjeg@miek.nl> From: Julian Reschke Message-ID: Date: Fri, 10 May 2019 09:22:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190510065425.iy74lntsbeeakjeg@miek.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:3qRjjTr7yS9Y9ve0VZPohGyokohS+ljvMAYxzxBCZoccN/TeQMK 6ZQtFlOWQMyIMJpMUO759L2lsyp1Kj+5weIRKtNj56bTM6qVGVQU1zaO/OLQ0pj2JS0CXIo TaW8PZBJcyk/Ko+spKE6heQXCEBMq4UsU90mJ2C7aM8dCo8CGB2ULRi4GcqPpQTay2ZEGKq DJSaHwSK9lNQRMvMcA+ew== X-UI-Out-Filterresults: notjunk:1;V03:K0:afnjlZQD9qw=:+G+pPTAOSaX8pMG1jXC8XD RmwkhTRcTu6SyvVeirW2jCTi7zxD1wf90Rrook3opPbP+K++OC4UCdmrexf3fjq4eW5udzmK/ 9Jarr4QYLR6OJ94hpShNhUSsKkEQBaoglElaonR8P6z+OORzje5mNi8olVSRECaurVdpdcDhm 5/BlqvnfD+1N52l3AcWyB/sVctXQCWljGHsgd/pHN2DEIm+P9mNVhVZZveJPZ1o7rISUgDzPI OhwH3UVsKrZY8FcVGpbxi0/LX79tYMpLpAy8Mk3xRaQd8X484B2KoDiGBG40qvl8PifMPQtD7 HBA8oFs63V4GoW5k1TIy9ah+SbfA6vKVzD9J71jvprX5zE3i/mmhBDsAN8zfQOxWmmXs98gwl /nqruGfEVSnQONomiT+yyrkJ0qzlOlvhA7Ko9umf17Mrz4yThgEn+BNOnS6brW7qPMLOKdYG+ 2rQpPz2YhXb24EOCqkeLmHJft2NWHRofB1rBX3uk8CqJTG3oAisTIOB34fi0DngCoM6N1athA bsDXC7BJ9VQZVtxMmAHnJRNosNZKU+PDlV/+y5fQete+eIr1VJAso0N57UgCMV/2McOqSG8eS zmz38rbXiRszk/YoXr46eoleGAzYhUu04aMQvTQZzupxYMgD7/T2HD+gkEBT1p8KkAQlF3eTP o+XMyV1WGmFF/CKFabRtN3+Piox1Nh4CdpICsiBFU4gpfnOhWGTrDZxZDI5VbL1Pv4CE/V2y6 4ENEaJERZ2iqUiYcQ32l079uQ8NRdOZKCjoyxndCLz94ejHkowNl491ivEmiREai8noHsv5Su +qPhRTGCtOezz6HwfpBWOyQLm1m1+EYRkx+qat1kOGX1y/Y1a9xnPB1VI+9xoZzhmaiRsr4p9 uJARgLUgaAZu+h7VVz96ZE2URitpXKJT66vgW3c9z+Y5gVnVn3Q9nLdRp1Ut+x2HVGngi8Pit jd8lNNfQbEw== Archived-At: Subject: Re: [xml2rfc-dev] docName? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 07:23:07 -0000 On 10.05.2019 08:54, Miek Gieben wrote: > [ Quoting in "Re: [xml2rfc-dev] docName?..." ] >> I'd like to know the rejection message from the datatracker.=C2=A0 Ther= e are >> any number of possible rejection reasons that have nothing to do with >> docName, even if the description in #76 seems to indicate that it's >> related. >> >> I may be able to fish the rejection reason out if I know the draft >> name and >> submission date.=C2=A0 Could you provide that? > > I've asked on the issue. Thanks! > >>> I know need to make code changes for something that is actually not >>> described >>> anywhere, but seems mandatory. >> >> You can expect that docName will continue to be needed. > > Ok, is this always seriesInfo.value ? > https://tools.ietf.org/html/rfc7991#section-2.47.6 > Esp considering this changes from filename for an I-D to a number when > the document becomes an RFC? > Also because there is a number attribute > (https://tools.ietf.org/html/rfc7991#section-2.45.7), which I added eons > ago because xml2rfc complained; maybe that can be removed now (because > its deprecated) ? > ... I *believe* for now it is safest to just do what RFC *7749* says wrt document metadata. Best regards, Julian From nobody Fri May 10 01:47:04 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08181201C3 for ; Fri, 10 May 2019 01:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 3LF778tmJeMQ for ; Fri, 10 May 2019 01:47:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA7C1201B7 for ; Fri, 10 May 2019 01:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557478016; bh=swfQOWpAUqI9qVi42K7vrOzxnaMAY1i0eqbhIbdqhjg=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=i4M0T0JQFGoVlYYiMO7LIKYkGK5RdZ0YDfjYV0HXPYNOuV3OaIDJuz2k1e8+yb60U TfZCtwVd7XcwjyOvz5DiztJeuEyG7GPyF7Qcw1G8eL4bygPT9nimBQ7Xn9Waet+EPd zOlz6qIuHoTMoGUVl0wEJGX8vZqUfNV97+8aQCJc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.148.236]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LvV1X-1ghSz51VpL-010fLp; Fri, 10 May 2019 10:46:56 +0200 To: Julian Reschke , XML Developer List References: From: Julian Reschke Message-ID: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> Date: Fri, 10 May 2019 10:46:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:JN1zjMDCMe0aaLPPIjEI5z97N03/Ya28kVhNt8l0khfcHI9CcyC vE4uV/nWPOFPYhaIYOdcl+1iRTJbpM5vkmjhV/Rvqlzb2QBwH/IXiN8vnMquA2HUQtGI+49 dKF8iGBIPTrWr3i7X2Z69uMOsw6voODqOmmp5wC3/XrmwLdlfCn2gKWiI5Iph3Sm6HJdwlI 5jgz4KsQ5xSf2oDeEpDSg== X-UI-Out-Filterresults: notjunk:1;V03:K0:KhvH/pKnJK0=:+ulzHtK518BCa7SCMtwJ0v zC4SN598EXALJKnTGfDl5f7rYi+SXE/8aLqw+W3aPsQenpTMp2b4sgWN2nx0+QbEN5vuFrFOt 5NSLsn8FLmd7seA34eTY1MOySCtrzfuvNA7NCC+sYE/wLBkR462pl7kJBinkFDQeNMW5gYo6o nF1owN+Hy2dWCbOnvsmdPlPEPT/YKh/18cBf8UPdGEb7nlS35jEVEhlhnfHl0TgnhuDQaLHCx UqKfpn9KGjDIbsDLlTqmwts0mYt0NXlplY87CTOqscPp3xQGnrQA8mmInyxdg4uVEAJZotklp 10SDZr+aojwknz1URhmhkLNdI/B+LyFzj2s/H4adTohQTqKjiYy99LSL/kgtbIIuXPG0tecGP fKjz/KZQN2/YxI+wUB/IXCD0qJIXgjcObvwhx3p3O/jDY6icxFRA1Ve03c/3co9qYvFcVOaJz gMqzsy+7+kLlEdBk8nzZv8mjULtDvYZZdF15tnb3aoT+z9dy+s7h2lqycAjJtKX4QVe45r2u9 Ql8Gwrc0vDIXA1B8l09q8RCs6ufsimsUz/wgos7F8lqKxeatiYEUUzme689aum29TbtpevSL+ wb3QxvPsBkFv4QxZY8iksF8kbt1gMHMVyrHnT3MdJvjBlgNfCDxxKrv+OQtY+qdB36kYv4VYp OHbcCLKeJZ0CMXSAV2dN1nBbHqp7we1jT72FGnw8xB6xNsTDP5qlMuwDlFJcRhAsGxbCOass1 nLVNWO43bAJEOBrLtggSVgHDFj+OqQiw+mKyl0pWgv8qBVsgtYYJGNCxwdt3n9FJBVnpq+GXq nZ5tV58Ovv3Nckj5N3yxScGtWlwxv5AZeb4yO61+Y43x3MhiA7t3JKVbApjedX6i5b4DWRnA9 iqS+oDFUbarW8geeBlkibjYuKiUL9SvGZn87P3oZbBUh613kWk8A66Tz8tJ4NTXeepfjwhR0o KT94alPJ61g== Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 08:47:02 -0000 On 09.05.2019 13:24, Julian Reschke wrote: > ... 5. Preptool behavior So the motivation for is: > The way has been specified to handle the presence of both > SVG artwork and text fallback (in Section 2.5 of [RFC7991]) has the > result that any SVG content has to be placed as a data: URL in the > "src" attribute when an ascii-art fallback is present. This makes > the SVG effectively uneditable once the preptool has been run, even > if the SVG artwork was originally provided as a regular SVG XML file > external to the document XML file. So I was under the impression that the preptool would deal with this by inserting elements when needed, and I was confused because the documentation doesn't say so. Testing with: > > +-+ > | | > +-+ and xml2rfc --v3 however gives: > foo.xml(225): Error: Found with both a 'src' attribute and con= tent. Please use with multiple instances instead. > foo.xml(475): Error: When looking for the name of " ", got: no such = name So something that was perfectly valid before is now a fatal error. Is this intentional or something that is on the todo list? IMHO, this input is perfectly ok (and indeed what authors would want to use), and the preptool should rewrite that if needed. Best regards, Julian From nobody Fri May 10 02:16:35 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D0012008C for ; Fri, 10 May 2019 02:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6uwfiyW6-sZ for ; Fri, 10 May 2019 02:16:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9AED120086 for ; Fri, 10 May 2019 02:16:32 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:50892 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hP1dm-0000BZ-2p; Fri, 10 May 2019 02:16:31 -0700 To: Julian Reschke , Julian Reschke , XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> From: Henrik Levkowetz Message-ID: Date: Fri, 10 May 2019 11:16:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kFg1wQ5akBiA13U8gxXFuJ1BdN3hLm86K" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@greenbytes.de, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 09:16:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kFg1wQ5akBiA13U8gxXFuJ1BdN3hLm86K Content-Type: multipart/mixed; boundary="vqdIJteOPGNRLgX99LP3fO0XU68wQFw1h"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , Julian Reschke , XML Developer List Message-ID: Subject: Re: [xml2rfc-dev] feedback References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> In-Reply-To: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> --vqdIJteOPGNRLgX99LP3fO0XU68wQFw1h Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2019-05-10 10:46, Julian Reschke wrote: > On 09.05.2019 13:24, Julian Reschke wrote: >> ... >=20 > 5. Preptool behavior >=20 > So the motivation for is: >=20 >> The way has been specified to handle the presence of both= >> SVG artwork and text fallback (in Section 2.5 of [RFC7991]) has the= >> result that any SVG content has to be placed as a data: URL in the >> "src" attribute when an ascii-art fallback is present. This makes >> the SVG effectively uneditable once the preptool has been run, even= >> if the SVG artwork was originally provided as a regular SVG XML fil= e >> external to the document XML file. >=20 > >=20 > So I was under the impression that the preptool would deal with this by= > inserting elements when needed, and I was confused because the= > documentation doesn't say so. >=20 > Testing with: >=20 >> >> +-+ >> | | >> +-+ >=20 > and xml2rfc --v3 however gives: >=20 >> foo.xml(225): Error: Found with both a 'src' attribute and c= ontent. Please use with multiple instances instead. >> foo.xml(475): Error: When looking for the name of " ", got: no suc= h name >=20 > So something that was perfectly valid before is now a fatal error. Is > this intentional or something that is on the todo list? "Before" meaning at which point in time? Are you claiming this is valid = v2? > IMHO, this input is perfectly ok (and indeed what authors would want to= > use), and the preptool should rewrite that if needed. ?? The preptool isn't in the business of converting invalid input to val= id. What you have above is invalid v2, valid according to RFC 7991, but not valid after the introduction of . Henrik --vqdIJteOPGNRLgX99LP3fO0XU68wQFw1h-- --kFg1wQ5akBiA13U8gxXFuJ1BdN3hLm86K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlzVQV0ACgkQTptXS4+7 Fxrw5g/9Ggld6t00+l1x628JO2PdkjzBt/76xMjKe1/+GK/eiOlXScriVUVJ79KQ psafBc8Me47+Yi3E951e+uVo6v1ToKv3Lc9B1PjEu6QrLc3JXTC7/iqQdlgnWXcp 9IhMS+NRQZw4211q+GP3KAgPMJYQV5OdMiZ0QmaYxUEwSnAvn5FZN2B1zjbIsTGO b5Kor7lDIBQLSYhQuw7+vXO2Wri812s2qTqnz9oHpX9FfSg0tGIuM1EK3P8eY3Do 0nHUfrF/p3ZH8kvC819rhNy/jR7mUpvXPpQVVqNDvQti3NMALamhA+Mwx/2ZUVyq JOJSd79mDHzoudh0uNzsCb3IbkIfIWXopKxRBfd/B/kHPQa1KEm7z1ZvFUOBip4a GnWsrfRVrMMtESGnXzBmxzFArPX0X5qSQasAomT/F3RuhskDIlYpNmdOb2zx6khD 1Z14sjOzPPr4PmQ+z58ZoA99J89aVc12YT3w6onPSvobKx1UdF1XClnccYQ2K3SQ b7OPxOOpDdsbVN5280Tnk/u1bithnWG2LxWko3YFXQ1N+QT1CeOL0kgs1jUHWiJM Q+cH+js9/517UIEpiNNkp7Mu8UFSUtGbOI/7TZrAd+yXUKjxjr6tNwGSxBFxUBeV icsXJbNVtzMzNFUwGpC/W5N+XRYHyU3KxjAC+FHio46G+1nghqw= =8G72 -----END PGP SIGNATURE----- --kFg1wQ5akBiA13U8gxXFuJ1BdN3hLm86K-- From nobody Fri May 10 02:20:07 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF901200F9 for ; Fri, 10 May 2019 02:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 DjHrl4HyG9V0 for ; Fri, 10 May 2019 02:20:04 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0338A12008C for ; Fri, 10 May 2019 02:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557479989; bh=p4LkBv9wQdRoCZ2hwrR7Xrnfmlr3lmHpqfrZt9fKbuA=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=KsQITsnm1dRTuLlrDsxy6o8t7kbS4LvXNs6CMONBS9bZn3N/qs404nBliA4ikdnqd jHuxXn1CnaMEC5SlGa2zAyfHrE4DGRtPT+wR7I/0pVXZyVv8iim1iI94CCVKRa4fxz ZIK+yOQUL2svr85HX+9WVGSJqgVxb9gcu39zUaSY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.148.236]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MKYsh-1hOCkE0IVz-0020jf; Fri, 10 May 2019 11:19:49 +0200 To: Henrik Levkowetz , Julian Reschke , XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> From: Julian Reschke Message-ID: Date: Fri, 10 May 2019 11:19:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:C3L5T1lbTTNx6ti7WUvQYKjU/rLKob/9Q85DnnFCKMQoHkNDpij vp0ZTKYa1PKiJtK3djZLmVkh+fQLwI/ZdUrhIVO0cB5Dqs9tEcgfgSxf0sOo/cBGKqtv23r AZj/qBAqxd0yUjpeaSDw8WROi5ZMY14llNY4OWLLgIjIaotLS4R5v375kqt7yW9FU7z8EO/ 4PNEfEV1l+PX3ZJeqKJhQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:gQNFq/t94Pc=:AaBW+Dx0tETR3WnS6xpa+s CSW/eE0VlXJegLE3Wjoek5wmMJK2QVRGFTONnrtdRQbGjU8txey5qVeZdvcqA3g4lJTEefuhZ 5pHAkSEEMUzp93G70YEatObLDvQNRR9ZKaJMzrJFufWOG6EPxTmxDAORa51RvRdtdnKZSNeZ4 4s7Ca+6Xc6By65ZDqQdu4WDflWPZ70D2lZYDkwZdjoywEMpDSxhCYUr+z235J1+TUgNeH3oyv aatoYQhzSIyE/atw6dH+Jq/AgeQU15EmfR9Q/A5ekJJEiCZvIIz3zPJCqgXtO7UbzuZajbToW hcsXkTxHfbwh1jyhG3XZlVllVVHuI0OzL6OdJUSqdW8DB3kJoP9CQFrRXzUl9kfO22wPE+dv7 7ZTGJOW23wpVpgACv2gBZHq5fu0/ohhUKLbC1aBiNjWcf4FTbq0UGi7l0ScPATK90NQjf0040 xHtQRXxK/+60voDvepjiD1dbHkI7+38y46z82ebL++2cafoLe+6tpys6DJpr+BU01z0ns+AYB eXPnlkflPwblPHFWPZrGgLUPkh85G26hzzewO32ASwhXCsDW6GaIQ4MKN66oQHVxHwCAkcYu5 zGBF0IwkYA5f/7b8EgXbaTI0Me98v563OfWeehkyOPEwV3+qAA+wgLRDR+Q9JbDSiCXx7/zqG hQa9nKVaj5/5OlwqQdn0v7s1U7TOUMAUFktGOm7TV+PgKQQyCiM0EqY4FCtiaUejvMsPxu9mv ha2hNgMUy3nlIE+go0TG2ysnIfeAmE6iYQyzP3zzfHQXHbpNNr125/zv16Lv8pFmiIHDCTXLl +tzyTVGeNqQXmkqP+7VciZkNHUByrVfyExG7XplDaWydXvF6adnGDdU+voHGLCCiwLQIvnPrs h0/YFw5kDaiWJ+Ecjeax3JSpukmcTAa+ZxgQAtClzVocwHb5WKFxtTKh2BIuRE3VZsTpNKSn2 SnJjJMtbOUA== Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 09:20:07 -0000 On 10.05.2019 11:16, Henrik Levkowetz wrote: > Hi Julian, > > On 2019-05-10 10:46, Julian Reschke wrote: >> On 09.05.2019 13:24, Julian Reschke wrote: >>> ... >> >> 5. Preptool behavior >> >> So the motivation for is: >> >>> The way has been specified to handle the presence of bot= h >>> SVG artwork and text fallback (in Section 2.5 of [RFC7991]) has th= e >>> result that any SVG content has to be placed as a data: URL in the >>> "src" attribute when an ascii-art fallback is present. This makes >>> the SVG effectively uneditable once the preptool has been run, eve= n >>> if the SVG artwork was originally provided as a regular SVG XML fi= le >>> external to the document XML file. >> >> >> >> So I was under the impression that the preptool would deal with this by >> inserting elements when needed, and I was confused because the >> documentation doesn't say so. >> >> Testing with: >> >>> >>> +-+ >>> | | >>> +-+ >> >> and xml2rfc --v3 however gives: >> >>> foo.xml(225): Error: Found with both a 'src' attribute and c= ontent. Please use with multiple instances instead. >>> foo.xml(475): Error: When looking for the name of " ", got: no suc= h name >> >> So something that was perfectly valid before is now a fatal error. Is >> this intentional or something that is on the todo list? > > "Before" meaning at which point in time? Are you claiming this is valid= v2? Yes. What makes you think it's not? > ... Best regards, Julian From nobody Fri May 10 02:25:35 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA46120086 for ; Fri, 10 May 2019 02:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Rr59i6qSI47 for ; Fri, 10 May 2019 02:25:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A47D120052 for ; Fri, 10 May 2019 02:25:32 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:50957 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hP1mV-00070j-M4; Fri, 10 May 2019 02:25:32 -0700 To: Julian Reschke , XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> From: Henrik Levkowetz Message-ID: <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> Date: Fri, 10 May 2019 11:25:23 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1vvTispQ5aHUoScKLKSUAKAh742TOmJwt" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 09:25:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1vvTispQ5aHUoScKLKSUAKAh742TOmJwt Content-Type: multipart/mixed; boundary="lddDWUMNMoHNDHQWk23Kjh7TxFNs4B1cO"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , XML Developer List Message-ID: <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> Subject: Re: [xml2rfc-dev] feedback References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> In-Reply-To: --lddDWUMNMoHNDHQWk23Kjh7TxFNs4B1cO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2019-05-10 11:19, Julian Reschke wrote: > On 10.05.2019 11:16, Henrik Levkowetz wrote: >> Hi Julian, >> >> On 2019-05-10 10:46, Julian Reschke wrote: >>> On 09.05.2019 13:24, Julian Reschke wrote: >>>> ... >>> >>> 5. Preptool behavior >>> >>> So the motivation for is: >>> >>>> The way has been specified to handle the presence of b= oth >>>> SVG artwork and text fallback (in Section 2.5 of [RFC7991]) has = the >>>> result that any SVG content has to be placed as a data: URL in t= he >>>> "src" attribute when an ascii-art fallback is present. This mak= es >>>> the SVG effectively uneditable once the preptool has been run, e= ven >>>> if the SVG artwork was originally provided as a regular SVG XML = file >>>> external to the document XML file. >>> >>> >>> >>> So I was under the impression that the preptool would deal with this = by >>> inserting elements when needed, and I was confused because t= he >>> documentation doesn't say so. >>> >>> Testing with: >>> >>>> >>>> +-+ >>>> | | >>>> +-+ >>> >>> and xml2rfc --v3 however gives: >>> >>>> foo.xml(225): Error: Found with both a 'src' attribute and= content. Please use with multiple instances instead.= >>>> foo.xml(475): Error: When looking for the name of " ", got: no s= uch name >>> >>> So something that was perfectly valid before is now a fatal error. Is= >>> this intentional or something that is on the todo list? >> >> "Before" meaning at which point in time? Are you claiming this is val= id v2? >=20 > Yes. What makes you think it's not? When did v2 get support for handling both a 'src' attribute and textual content in ? Henrik --lddDWUMNMoHNDHQWk23Kjh7TxFNs4B1cO-- --1vvTispQ5aHUoScKLKSUAKAh742TOmJwt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlzVQ4MACgkQTptXS4+7 FxoRzg/9EOE7wWOHgkocCMs/CONQxHQwk4Yp6QA32lD2nq/27tKfBbyae4F5HWPL banPyyyNoMpNQlRPynb1Ym5FEAtKFrZLdLvuJyBDZcEyCiNuHdJnMsSxwITjIbf3 ZlICN3b168bkrcf3NIbhiYG/Bq+6rY5iACrmeDKWVNLNRWRfPom/fNSuOry1pRWi yN1uBAihuZaPVIvm68in6soWYY0MHDPnCWU/grzLuQ7GvF9vl+JAv0Y9eZpC3ybq Nb+LEBd5hrzjwCpbOQwj7iih3T5b29t2E2FF1RTvgp3uV8/NsVWHY//AWShC8wtO 8Gn5574rhNhDHwboptmJL9W2NY5aZcGxnKosZkTjqm2UZrsvzHeBXyPbew6QSYDB vX+UKo8i3BMgvOm5ju54hxC7mvzB+Q+BeLdEXdGbyN5h8djXS435vGc+F2MdWt0q tGDtFaz/BObr7jTLqnIlBrtLW/pW54kVN8hTdmpP4u5oo20K1lJOO68UHJZnOUFL xS+VT+UV3U/WojuPO88O+iMZkpo833DIIrCaKd7QaBGPgblPT98KwVcM1MXqqMO9 Gw9bgoHeTxT0Bff/UsWXIFrF9E+O0GlyIzBIbcAq4S7jvJgICZwIY0Hu1vQ1G5rW cpS4xSh+EYc7SpStaSyqZlYRgTEPFEhfMIaiVlPP2Fg+JPBe72A= =ekbj -----END PGP SIGNATURE----- --1vvTispQ5aHUoScKLKSUAKAh742TOmJwt-- From nobody Fri May 10 02:38:45 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F6E1200F5 for ; Fri, 10 May 2019 02:38:43 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 85x5Aj-PtrIU for ; Fri, 10 May 2019 02:38:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACEBF12002F for ; Fri, 10 May 2019 02:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557481106; bh=pmaV/DUPS1H/dFstuKrw2knBsxGZ2BZScaYwgEZiY+8=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=Xf27EuEnWuLpTDaFWt524RRRSPXDxTDlen0HueREOsQXO7VKA1CGK+52LlgEVeuOB R2N7ytz32vz5Zpys/shy8OUva13IC0FSbzuTLazRHT6vB/nyn7ritFD1ox7CAcC683 yDxHXj/Skfe6H7bLYmef9tlsBOOcxegjmQfi3IO0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.148.236]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MFcg9-1hS6WV0ppF-00Eco9; Fri, 10 May 2019 11:38:26 +0200 To: Henrik Levkowetz , XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> From: Julian Reschke Message-ID: Date: Fri, 10 May 2019 11:38:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:OYNtATM4J7zJoUh2C2Xn+QZ2cy3Z//eRqq+JNVop5CsM+YC7is7 Ly7CyeEdbEvtyAqvWyOrXDI7QfnT8rnS3IjIvNgHCqvGLgZqBjG8/kvM5/CHeIejBDXdUxq 84zfW1kC4R9wFMPc2xEplnzzjwV4252uOV2/t+Q0w8g49R1s9Fip5DgB8uDIDufu9kEByyA lbXUMU+X9iOd0kfZ5GAtA== X-UI-Out-Filterresults: notjunk:1;V03:K0:w9M/lqLrt/I=:Y4Ag+Bp5aPKtEXzzW79U9Q 9Zzbrdrj0M3leZKT0W6YxDEYlvArLI8P9vM3nJFocEGSaq+xbASkshWP43TsrEAf8V7urgYmc Ytm3E9Zev0AxoNLGUGJG8VgQnDWDNVw5vzikS67+mMliZ5huVun9Wr5pYWRodbijWYd9oaLWp xaWKgc5KYU9zjwv9ify2bfMHNmlPs1dcglshCMOzHl8xA6dVoKGZQaVK0jFByacfAenQAG7/j 837ny5KjTCbRWYfhv9As+/APeP6gDC2lmxZNwvTV2bdc/j5PTsHFHbTCC1AsJaD+B+u02eFwP qL/9qMa8Ms5TxWqVt6XjZV+9QfNSTVVtOctzErEEXN9TUH/eZr/X6bsw4eaa4NSEHI7hsdPcl PGWAt0fTtMJUL1m5Yo8okSM8B3PLIseRqYVivrysUL2hnxrgULpVAqhYhEaR+PpmdgB1M0/jt h/N4EtKPq1r6KJMDfy4meQM1wBrBNtRpgEU+FuMxktP1rbNjBkz8Pg+lQw7E4f6DN07peIaTh yivGoh9wWC38todrOwGTpCohAE73L6SxpTnrwQkz39rWtXtUQaqlpXhtJGH/MysbTKPSYxOrc zar5ny4oJcGfCZhHBqMvsQOIEczqjUNji2JuQsAx7Ra0uKaxpEhslvlDx/5ftKDfL/ERRs8ra 2rr9LAFepduSU4Yt3q0WSSHAAm45IOzBfUr2YkRiVp1GhhBRoTsBacV0m6MxjeVWO+CAzmcES QM/1/tsRozmFt9YId31NeayxFpKvwEdU7AvMTaWD61Baz4RD2LbLl1O5j+y2yOt238iy2QgCF 9ffxrBHFBgqJiDd6g4B+oqUphkUec8pjkPzPsgO6Sek49gK6vfnDds9lwh0XJDZk0bgYtFcUh 06onxXREh5HsGcqQS/XzbnzY4Wkxl4ifZK6vAYCO8PB07P2gtT3wQ6z/Rs5L6NrX8+BSctN6F hSqMeH+vO4Q== Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 09:38:44 -0000 On 10.05.2019 11:25, Henrik Levkowetz wrote: > ... >> Yes. What makes you think it's not? > > When did v2 get support for handling both a 'src' attribute and textual > content in ? > ... For at least ten years, I'd say. Excerpt from rfc5598.xml, dated July 2009: > align=3D"center" > alt=3D"[ User, MHS, User Service Model ]" > name=3D"Basic Internet Mail Service Model" > src=3D"email-arch-fig-svcmodel.png" > type=3D"image/png"> > +--------+ > ++=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| User = | > || +--------+ > || ^ > +--------+ || +--------+ . > | User +=3D=3D++=3D=3D=3D=3D=3D=3D=3D=3D=3D>| User | . > +---+----+ || +--------+ . > . || ^ . > . || +--------+ . . > . ++=3D=3D>| User | . . > . +--------+ . . > . ^ . . > . . . . > V . . . > +---+-----------------+------+------+---+ > | . . . . | > | .................>. . . | > | . . . | > | ........................>. . | > | . . | > | ...............................>. | > | | > | Message Handling Service (MHS) | > +---------------------------------------+ Best regards, Julian From nobody Fri May 10 03:00:36 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA5C1201D0 for ; Fri, 10 May 2019 03:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUaQchJEvrfI for ; Fri, 10 May 2019 03:00:34 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBA11201CB for ; Fri, 10 May 2019 03:00:33 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:51248 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hP2KO-00025u-UH; Fri, 10 May 2019 03:00:33 -0700 To: Julian Reschke , XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> From: Henrik Levkowetz Message-ID: Date: Fri, 10 May 2019 12:00:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xmCxlDW9ICt4eKfogw3tku95BOSS3KWiA" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 10:00:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xmCxlDW9ICt4eKfogw3tku95BOSS3KWiA Content-Type: multipart/mixed; boundary="jMqPEOwiB9v0U8cDNJTTgJejijVl6uTPi"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , XML Developer List Message-ID: Subject: Re: [xml2rfc-dev] feedback References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> In-Reply-To: --jMqPEOwiB9v0U8cDNJTTgJejijVl6uTPi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2019-05-10 11:38, Julian Reschke wrote: > On 10.05.2019 11:25, Henrik Levkowetz wrote: >> ... >>> Yes. What makes you think it's not? >> >> When did v2 get support for handling both a 'src' attribute and textua= l >> content in ? >> ... >=20 > For at least ten years, I'd say. >=20 > Excerpt from rfc5598.xml, dated July 2009: >=20 >> > align=3D"center" >> alt=3D"[ User, MHS, User Service Model ]" >> name=3D"Basic Internet Mail Service Model" >> src=3D"email-arch-fig-svcmodel.png" >> type=3D"image/png"> >> > +--------+ >> ++=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| User= | >> || +--------+ >> || ^ >> +--------+ || +--------+ . >> | User +=3D=3D++=3D=3D=3D=3D=3D=3D=3D=3D=3D>| User | . >> +---+----+ || +--------+ . >> . || ^ . >> . || +--------+ . . >> . ++=3D=3D>| User | . . >> . +--------+ . . >> . ^ . . >> . . . . >> V . . . >> +---+-----------------+------+------+---+ >> | . . . . | >> | .................>. . . | >> | . . . | >> | ........................>. . | >> | . . | >> | ...............................>. | >> | | >> | Message Handling Service (MHS) | >> +---------------------------------------+ And what was the v2 handling of this? Henrik --jMqPEOwiB9v0U8cDNJTTgJejijVl6uTPi-- --xmCxlDW9ICt4eKfogw3tku95BOSS3KWiA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlzVS7YACgkQTptXS4+7 FxpZMg/5AT8jeteQICcbeOA6/bccUOBr/3jl4/d1MgNNxg05bkiyPLcIxSqEYBfF 4O1Ow43CUQt0apS8E99SCR1CzuP7gF+IJFWFx8a3YIw6SAdExCCupEPOwFDbiFQL AJOtACDeJXR5bdvv19Iy/OL7PiIXStzuIOMJIYL3th+cVOYZNGOwLFw8rVlHemyR aZYitc08i9UEftS0L4uaRW6dD/ZRcEQ5bmLG4NyfO2iqIWQgevXOzJkEnLwat0v6 7weX4p7oAPSLLSoFQb5+QsR6R2Vwgg+F3HQ9m30hz67jo3lRazRvbN70p/eP+hdO mudnEZyPrAaVAo3pk80z9IZp6GxTUqp5wXoh7t/+fxcTMtnXinfAaK7n7D9SGCUv bH+VKjxPkMbKs8gUrg5M+NjAjKDXZfbNJsbN5ws3oC9KCA9Aho4fzTxHb16ZRsCT VYKoxnGlfVF5v3bL7WWTk0QY1Ns7qS9r5qD8OTDKXh2kxP/uswZ9vsiYFAyb6Ayo t+PhSM5hBcMJwtT7wSNjloieoJ2u2IbTwV5XK/VhSvQDploTtACs2GE8Ftx8r2hp w4hju6jSU/5d6zmhR5MtGkCsIEp2w2omVmBDgwWueteb0s+F0QmnRPyjrCsd4ltz ldoGlDXmblOQujrT/AObLka+JrtSXhucG7vugV828+Dwhl6UK5c= =BaY2 -----END PGP SIGNATURE----- --xmCxlDW9ICt4eKfogw3tku95BOSS3KWiA-- From nobody Fri May 10 03:07:13 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F004712023E for ; Fri, 10 May 2019 03:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SUBJ_BRKN_WORDNUMS=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVpR59nJ3f4x for ; Fri, 10 May 2019 03:07:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A46F120234 for ; Fri, 10 May 2019 03:07:09 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:51315 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hP2Ql-0000Ih-29; Fri, 10 May 2019 03:07:08 -0700 To: Julian Reschke , Miek Gieben References: <20190408214850.fbwdzhza7g4omyvs@miek.nl> <20190509060348.77yjfr3uuff7e67j@miek.nl> <9f6f2abd-5cda-2611-b1e6-4e912a17f5bb@levkowetz.com> <20190510065425.iy74lntsbeeakjeg@miek.nl> Cc: XML Developer List From: Henrik Levkowetz Message-ID: <98223d05-21ec-e914-046d-30c9dcb0a695@levkowetz.com> Date: Fri, 10 May 2019 12:06:59 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cFEidnjkjRdX9AqTgowmDKSUGBlwg8Hk5" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, miek@miek.nl, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] docName? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 10:07:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cFEidnjkjRdX9AqTgowmDKSUGBlwg8Hk5 Content-Type: multipart/mixed; boundary="XSRUbebMf19bUJ9Dfg1kiWCTaMuJubqsD"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , Miek Gieben Cc: XML Developer List Message-ID: <98223d05-21ec-e914-046d-30c9dcb0a695@levkowetz.com> Subject: Re: [xml2rfc-dev] docName? References: <20190408214850.fbwdzhza7g4omyvs@miek.nl> <20190509060348.77yjfr3uuff7e67j@miek.nl> <9f6f2abd-5cda-2611-b1e6-4e912a17f5bb@levkowetz.com> <20190510065425.iy74lntsbeeakjeg@miek.nl> In-Reply-To: --XSRUbebMf19bUJ9Dfg1kiWCTaMuJubqsD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Miek, On 2019-05-10 09:22, Julian Reschke wrote: > On 10.05.2019 08:54, Miek Gieben wrote: >> [ Quoting in "Re: [xml2rfc-dev] docName?..." ] >>> I'd like to know the rejection message from the datatracker. There a= re >>> any number of possible rejection reasons that have nothing to do with= >>> docName, even if the description in #76 seems to indicate that it's >>> related. >>> >>> I may be able to fish the rejection reason out if I know the draft >>> name and >>> submission date. Could you provide that? >> >> I've asked on the issue. Thanks! >> >>>> I know need to make code changes for something that is actually not >>>> described >>>> anywhere, but seems mandatory. >>> >>> You can expect that docName will continue to be needed. >> >> Ok, is this always seriesInfo.value ? >> https://tools.ietf.org/html/rfc7991#section-2.47.6 >> Esp considering this changes from filename for an I-D to a number when= >> the document becomes an RFC? No, the docName should not change to a number; the docName is used to add= metadata about the draft from which an RFC is derived when writing a v3 RFC in html format, and to insert the draft name when writing draft outpu= t. >> Also because there is a number attribute >> (https://tools.ietf.org/html/rfc7991#section-2.45.7), which I added eo= ns >> ago because xml2rfc complained; maybe that can be removed now (because= >> its deprecated) ? No, as Julian indicates, follow 7749 with respect to metadata. The numbe= r still indicates which RFC number is to be generated. Henrik >> ... >=20 > I *believe* for now it is safest to just do what RFC *7749* says wrt > document metadata. >=20 > Best regards, Julian >=20 --XSRUbebMf19bUJ9Dfg1kiWCTaMuJubqsD-- --cFEidnjkjRdX9AqTgowmDKSUGBlwg8Hk5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlzVTUMACgkQTptXS4+7 FxoUNA//eSnxgWOn4VyStPeuUHGBD7/IefVpyMne/gMjbNJSDVAlmEcv7LQqP2cS 6I+7IKZc8tO8hDo9W7252M2gpMzLps2qvSkGd/snASuUtwUS9s9ZY2fNDiSdSBLR Fgpa9EZQlyAohIgAXjiDppdK0Lw95mH/OerYBOcxmQaDmh0MwYKvao7kHQ5sjjDo KhOSK1bKhGt9PiGjEFF5bQG/nwK/TZFxl2VD25Ld06kPlvCVXO5ZsMoUnU6IrpOZ LGKmSOsLIpfvXGeGArmUc9V+/NVeAY3jvcLRi4MLZ/7+vlucXM0tdmVOgbKRLvAr SkPoYUu2e3QZkGEooF7iM+H9owoWx/DXCeh6jc494dOFF7TtYY82BpmwDr2Mq9od TW6aSsDWNASUDqUUuTBbnKvs5cXBm0RbUYddLjZGu7cMeu6as8LzzE9S/q1N2OcJ 2mge6O/JNQ9YtCINwnSfe3I6gE4ne4y+/auIYkYcgbiE0AcWtSVwmM1k9+uEempr IuuK2NpL4PccMimA6+2UvLF5nnwATpXOi0pk0dTJAZ43cv9RB8NJG0ildb0d0m8f IWgJbhBwRVPuaHIRcd9tBhnNVuU4qbyL3rGSIg2CtG7XTkqtWyO42VjiaRogMY7A olbPdfjBZjAkdxPOpG8LLc+oZL7AQhCj9gTBB7FWJgBmc7AUo7k= =gD5e -----END PGP SIGNATURE----- --cFEidnjkjRdX9AqTgowmDKSUGBlwg8Hk5-- From nobody Fri May 10 05:03:04 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96841201F2 for ; Fri, 10 May 2019 05:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.436 X-Spam-Level: * X-Spam-Status: No, score=1.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL_CSS=3.335, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com 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 yTxdZdbcnczj for ; Fri, 10 May 2019 05:02:49 -0700 (PDT) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5A71201F0 for ; Fri, 10 May 2019 05:02:47 -0700 (PDT) Received: by mail-yw1-xc2c.google.com with SMTP id 18so4521657ywe.7 for ; Fri, 10 May 2019 05:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=CdeHrzO2FFvhFOwSjvW7PxqRUM1g9TIx/bDaJo+lWh8=; b=KlLWbqLEO6cW81qWHNAjIGFM3c5HW0xVWDp0GFkHKTlnfj+zg83ZAFEro4tFhThAeQ E2o8pF1NGH/qiXngGUxGKMHBPBTyHqte0nAzIlsypmaf41S506pF3JmbQcsOYslEnhHo lifIrJhXGGRvp7RnV51b0weqhHRyRdIdvRbrtC0kDUDey58r63+742nAV1LTYwRy1eWb u0pOlPuIj1fhDLNaKoHl+kfM8D74uyirKhbGUTAzmg7tD8ev6PH3Vnhpgo7qOTtX+E9A 9UgRVia7pu3sgYzkOhqYGH3VDFv6I/b/63QK7w0cZHhW97gOfNA5ueNuCxDi/TjmNeBT grAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=CdeHrzO2FFvhFOwSjvW7PxqRUM1g9TIx/bDaJo+lWh8=; b=pOOJzTOsChLTBl6SxfaLjHoRJk96m+UtZs05KyKcpPlcvg/uCtKZxn55gMObbVZoBj 1eDEKCSkgtDXxLRWk045/ju6kr23OcUbUeGTSC55z9xUVsqKzrqbSoAU6/SJvrZF+W1w WZeEsQfoY448/tZV5OC1Se8jBGI3v+87sKWzD5fLI2RwbQrsCxJL2fg4/0gydQu7RgeU WJdCR2r3wUjGwMSNyrAAWRCCwibPcKNaaXE/vNuReTvOglgUYoD9pxap6jUUZHTP/8GC F+ax6UGuXQn2tmbjcYjhnjyTV87xShojmPvpBuT7qNI9Fpww9rq79RqXXrFGhOcjGdJm mlHA== X-Gm-Message-State: APjAAAUczf+tCoLWp6FrUaVJdrjHxWXaimLxIgMBHx5Da8n5LCRnK5Vq du5/jj1RbN0VYMa6WxvPExEqgw== X-Google-Smtp-Source: APXvYqyA+3HspH2hoLPGobenNuyqMS8T2HdA70WvOUykwXNrgUGFZMLVIXormjAt+/YPQMRsBopVcw== X-Received: by 2002:a0d:e343:: with SMTP id m64mr5655370ywe.368.1557489767115; Fri, 10 May 2019 05:02:47 -0700 (PDT) Received: from miek.nl ([216.172.64.18]) by smtp.gmail.com with ESMTPSA id i67sm1529926ywi.103.2019.05.10.05.02.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 10 May 2019 05:02:46 -0700 (PDT) Date: Fri, 10 May 2019 13:02:44 +0100 From: Miek Gieben To: Henrik Levkowetz Cc: Julian Reschke , XML Developer List Message-ID: <20190510120244.dl2sg3qopbb4qd4b@miek.nl> References: <20190408214850.fbwdzhza7g4omyvs@miek.nl> <20190509060348.77yjfr3uuff7e67j@miek.nl> <9f6f2abd-5cda-2611-b1e6-4e912a17f5bb@levkowetz.com> <20190510065425.iy74lntsbeeakjeg@miek.nl> <98223d05-21ec-e914-046d-30c9dcb0a695@levkowetz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <98223d05-21ec-e914-046d-30c9dcb0a695@levkowetz.com> Archived-At: Subject: Re: [xml2rfc-dev] docName? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 12:03:02 -0000 [ Quoting in "Re: [xml2rfc-dev] docName?..." ] >No, the docName should not change to a number; the docName is used to add >metadata about the draft from which an RFC is derived when writing a v3 >RFC in html format, and to insert the draft name when writing draft output. > >>> Also because there is a number attribute >>> (https://tools.ietf.org/html/rfc7991#section-2.45.7), which I added eons >>> ago because xml2rfc complained; maybe that can be removed now (because >>> its deprecated) ? > >No, as Julian indicates, follow 7749 with respect to metadata. The number >still indicates which RFC number is to be generated. > > Henrik Ok, thanks for the info; I'll make those changes. One more question if you have docName will xml2rfc; will this work as well: Warning: Expected a with rel='prev' providing the datatracker url for the origin draft. From nobody Fri May 10 05:20:30 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B44C1200CC for ; Fri, 10 May 2019 05:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 pfJMamR9YSjb for ; Fri, 10 May 2019 05:20:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6F5120006 for ; Fri, 10 May 2019 05:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557490808; bh=b32ow+0zlRrMzIMicUOhh6jMnWIWvxS1bBi97T377fw=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=ObypFw91G+Lwr4lJSGNmurze47moNSQnQhex6Yc583v8sq1Q2POa6MELMsqHJcLYY 74XrDoBT5N1k/Uibmw0gPYlxbmBYpaHwWY0nO2xGLVgm04c7ta2L+N+RSkmykxhOoe 7G+hnZKlk7Hk7sGDhGXDHjlqCdTgSl9GtQ1QTXGE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.148.236]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Ml6mE-1gzrcq0DAC-00lTMF; Fri, 10 May 2019 14:20:08 +0200 To: Miek Gieben , Henrik Levkowetz Cc: XML Developer List References: <20190408214850.fbwdzhza7g4omyvs@miek.nl> <20190509060348.77yjfr3uuff7e67j@miek.nl> <9f6f2abd-5cda-2611-b1e6-4e912a17f5bb@levkowetz.com> <20190510065425.iy74lntsbeeakjeg@miek.nl> <98223d05-21ec-e914-046d-30c9dcb0a695@levkowetz.com> <20190510120244.dl2sg3qopbb4qd4b@miek.nl> From: Julian Reschke Message-ID: <6dad1367-79f2-7dc0-3304-a8724dda0807@gmx.de> Date: Fri, 10 May 2019 14:20:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190510120244.dl2sg3qopbb4qd4b@miek.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:b+rQyrPvPY3+Jsycrpr9JHD6uCi534XMhzRXYOAU/acKQJov3xw wH/332vwYjWk0QsGMI7Z03DI1PkJkzfr+OJyHW4mv2G/n9VbqLrVmaaH+8ggqLmPtpzp3Sh CNEWvUaF+TodNUTKDvSb1cH5B8cDl3u9ZbjFdpJMoPoDtDv15ICU4eQAxJBkuAjIo69+p0W Arc2xR3vUtNOZBC2QUeXw== X-UI-Out-Filterresults: notjunk:1;V03:K0:TviF2yYbZuc=:eGF9ZnWESerh//h5VWs832 o6r5ofaWoU+bOAJUvgbrszYJwtuk2jSltnDuSZJaQ9gdB00GOBdfudY9Pi6cimvuDNpozOY26 3LygEP/MXEGiQwcWp8c/ZRX5zAVbU+2ckEhEVu4JYC+D1fiYhZuVrUldQYdk24ISYY1EYsKee bsdjJbmPD1bnUFjRLKr0wyjWKRE5QlO8XEScV04yKeAzg41uA+PFs2x6T35rScOARzlcR55PM SiWKmhIXhkdpBiT1HzntEDHLhtSpldDz6OAZNzte8biJ001mzlUwewPSuM7soEUTM9IhKUFkc X/4PbeaPMRS+QzYhRd9dVC4jcksO6HwhYx5ZS/7Xl58hl38raC6Awz+tGfS+VLqCdywPh/WvM kZmytRTyt7ifpCAXNO6+oWue296ryQmcDp0kh9jEe1h6/9t3xJoOcwdAr1ZW4kDUEJF0H+nQF zpguJC9Q1h5z5o4vU+C2UAzaNF5MTt2hBngO/GfmhdFHwguQy1LBrogdKTn668sJjEoWV/bqa iFlDnWp0R69ntV0T9CoBYdcZJd8Xqa5hi7WF6o6Bgs9lzj2zz4sxVCScmYO74bu/pUz2FxtN+ C+iwk1NLiGi7UB+ZyGKG7LKjyNnn5eZCmBdYw1cmsvHANPYGrnVIzUS8v1qav6EXlIuj0tnE9 WXbklPKC3xc4JBZLEddgo71W5dE7NO3s4V9Tv1fzEUz8qcaHkASZet22G0s1D0U4D0Lk6GyRL sOFvlBrfw03EgZBddeayo+xXoXw72cGTMcEk0+UdE4VkfcN5lYISi5NyE0mT5hIS9QNIngwGa PuQFYrIaGU5ygUIauT+abmpGq1Z3BIRiG1uY7f+D93oN4qJ/RuJtQg4XQps8b00lIxQdAY3Sd C9M6RusXIUq0pKCO9+xpUbeQEiXMKpvtsVEKCZwuxoN6vqZEZfADziLQzuU5Vdz8S7ltDQaDd 1CIgJ9d4OeQ== Archived-At: Subject: Re: [xml2rfc-dev] docName? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 12:20:28 -0000 On 10.05.2019 14:02, Miek Gieben wrote: > [ Quoting in "Re: [xml2rfc-dev] docName?..." ] >> No, the docName should not change to a number; the docName is used to a= dd >> metadata about the draft from which an RFC is derived when writing a v3 >> RFC in html format, and to insert the draft name when writing draft >> output. >> >>>> Also because there is a number attribute >>>> (https://tools.ietf.org/html/rfc7991#section-2.45.7), which I added >>>> eons >>>> ago because xml2rfc complained; maybe that can be removed now (becaus= e >>>> its deprecated) ? >> >> No, as Julian indicates, follow 7749 with respect to metadata.=C2=A0 Th= e >> number >> still indicates which RFC number is to be generated. >> >> =C2=A0=C2=A0=C2=A0=C2=A0Henrik > > Ok, thanks for the info; I'll make those changes. > > One more question if you have docName will xml2rfc; will this work as we= ll: > > Warning: Expected a with rel=3D'prev' providing the datatracker u= rl > for the origin draft. FWIW, that's a requirement that doesn't make any sense at all - I would ignore the warning for now. Best regards, Julian From nobody Fri May 10 06:03:49 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE7012011F for ; Fri, 10 May 2019 06:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SUBJ_BRKN_WORDNUMS=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0f7YYOMbspTc for ; Fri, 10 May 2019 06:03:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE44120020 for ; Fri, 10 May 2019 06:03:45 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:52851 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hP5Bg-0007Ak-9q; Fri, 10 May 2019 06:03:44 -0700 To: Miek Gieben References: <20190408214850.fbwdzhza7g4omyvs@miek.nl> <20190509060348.77yjfr3uuff7e67j@miek.nl> <9f6f2abd-5cda-2611-b1e6-4e912a17f5bb@levkowetz.com> <20190510065425.iy74lntsbeeakjeg@miek.nl> <98223d05-21ec-e914-046d-30c9dcb0a695@levkowetz.com> <20190510120244.dl2sg3qopbb4qd4b@miek.nl> Cc: Julian Reschke , XML Developer List From: Henrik Levkowetz Message-ID: <1b53c89f-6e5b-d009-5d6c-b672bdd02267@levkowetz.com> Date: Fri, 10 May 2019 15:03:36 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20190510120244.dl2sg3qopbb4qd4b@miek.nl> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gFD2X1lPNAGhnb4TJIDnFxENaE7jbiixC" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de, miek@miek.nl 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 zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] docName? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 13:03:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gFD2X1lPNAGhnb4TJIDnFxENaE7jbiixC Content-Type: multipart/mixed; boundary="KwfPlJCJb97L12lmdUTK5j0BwmLGTtfuC"; protected-headers="v1" From: Henrik Levkowetz To: Miek Gieben Cc: Julian Reschke , XML Developer List Message-ID: <1b53c89f-6e5b-d009-5d6c-b672bdd02267@levkowetz.com> Subject: Re: [xml2rfc-dev] docName? References: <20190408214850.fbwdzhza7g4omyvs@miek.nl> <20190509060348.77yjfr3uuff7e67j@miek.nl> <9f6f2abd-5cda-2611-b1e6-4e912a17f5bb@levkowetz.com> <20190510065425.iy74lntsbeeakjeg@miek.nl> <98223d05-21ec-e914-046d-30c9dcb0a695@levkowetz.com> <20190510120244.dl2sg3qopbb4qd4b@miek.nl> In-Reply-To: <20190510120244.dl2sg3qopbb4qd4b@miek.nl> --KwfPlJCJb97L12lmdUTK5j0BwmLGTtfuC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Miek, On 2019-05-10 14:02, Miek Gieben wrote: > [ Quoting in "Re: [xml2rfc-dev] docName?..." ] >>No, the docName should not change to a number; the docName is used to a= dd >>metadata about the draft from which an RFC is derived when writing a v3= >>RFC in html format, and to insert the draft name when writing draft out= put. >> >>>> Also because there is a number attribute >>>> (https://tools.ietf.org/html/rfc7991#section-2.45.7), which I added = eons >>>> ago because xml2rfc complained; maybe that can be removed now (becau= se >>>> its deprecated) ? >> >>No, as Julian indicates, follow 7749 with respect to metadata. The num= ber >>still indicates which RFC number is to be generated. >> >> Henrik >=20 > Ok, thanks for the info; I'll make those changes. >=20 > One more question if you have docName will xml2rfc; will this work as w= ell: >=20 > Warning: Expected a with rel=3D'prev' providing the datatracker = url for the origin draft. The v2v3 converter inserts a with rel=3D'prev' if docName is given= ; for v3 xml you should set that. I think, however, that this warning shou= ld more correctly be a note or comment. Best regards, Henrik --KwfPlJCJb97L12lmdUTK5j0BwmLGTtfuC-- --gFD2X1lPNAGhnb4TJIDnFxENaE7jbiixC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlzVdqgACgkQTptXS4+7 FxotFg/+MXe3ZGH6JUkDgvVxY9SOIusLtVHOsp2liiEfCIMjiGlBYYcOuhgwSHgp 8npvRX+wGPr1exWgm+1Uuq8twsk6sMJjEwb+CQeVgXkwKmguGhTEi1+UkaWducCS NhTK9nl89elO4BL38KWAQEnixFFChtg8HxvTv9lmJEyypsB0YjuKnR8nYv8lqOL3 o5LKqeHzfq703+cbvxPLVGPvDi+C5XHBgRwzClz0UlITiyZPMHs0mcClfVk28pHf AAjzs7Lfe3gMfpddEUIqUO4bSMJWp9SBnuS0rNjqMmvuNxkqdHbxrmbC8cHA9mXj 79GPXXooCuAK7umQq/iTpkwR4tXfJjHk5YbRJNg1XEA8MAGuMiCyHGWZHwnHEEgp Nv1YvO6QKXxBLdgzPgvvQbNl77E2PJPbIZka6UVbxZtpLXq4aEO4fmzx/PrxMBBC djUupDK4XUwg+R6cREikWQOYFNYQNuhpl7AaODqFOzF75EoZ8XnXR7UHTDrdZ7Ur Mko1prhGVvjJ5GeVcovpKiHHozJrdDgszFRoo2NgKJOLoAKrpH0YHkwCYhXCP6+O UrrVYDkqhE7H2gcnNVfEGRKscyUv4cIv92ENhr4gsB1jpwQLOkbRbVOLD+V2nN08 dL/5WYaZq4qC5+M0oQPuCZPcG2dN5YRYuBIbPETTj3HWr0PXJQI= =CLhE -----END PGP SIGNATURE----- --gFD2X1lPNAGhnb4TJIDnFxENaE7jbiixC-- From nobody Fri May 10 06:10:00 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82A912011F for ; Fri, 10 May 2019 06:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SUBJ_BRKN_WORDNUMS=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJkq5JDB8_VY for ; Fri, 10 May 2019 06:09:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49312120021 for ; Fri, 10 May 2019 06:09:57 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:52911 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hP5Hg-0001Yl-A6; Fri, 10 May 2019 06:09:56 -0700 To: Miek Gieben References: <20190408214850.fbwdzhza7g4omyvs@miek.nl> <20190509060348.77yjfr3uuff7e67j@miek.nl> <9f6f2abd-5cda-2611-b1e6-4e912a17f5bb@levkowetz.com> <20190510065425.iy74lntsbeeakjeg@miek.nl> <98223d05-21ec-e914-046d-30c9dcb0a695@levkowetz.com> <20190510120244.dl2sg3qopbb4qd4b@miek.nl> <1b53c89f-6e5b-d009-5d6c-b672bdd02267@levkowetz.com> Cc: Julian Reschke , XML Developer List From: Henrik Levkowetz Message-ID: <2d91ecfd-5212-ee60-f82b-c1cae9e1cbc2@levkowetz.com> Date: Fri, 10 May 2019 15:09:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1b53c89f-6e5b-d009-5d6c-b672bdd02267@levkowetz.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="csfIuxjiWv5b6lmpVlgmohK7tFSMiLdXn" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de, miek@miek.nl 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 zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] docName? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 13:09:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --csfIuxjiWv5b6lmpVlgmohK7tFSMiLdXn Content-Type: multipart/mixed; boundary="Daf9dKNCj2DNW84j7wqG1NkqaXFoMtTnI"; protected-headers="v1" From: Henrik Levkowetz To: Miek Gieben Cc: Julian Reschke , XML Developer List Message-ID: <2d91ecfd-5212-ee60-f82b-c1cae9e1cbc2@levkowetz.com> Subject: Re: [xml2rfc-dev] docName? References: <20190408214850.fbwdzhza7g4omyvs@miek.nl> <20190509060348.77yjfr3uuff7e67j@miek.nl> <9f6f2abd-5cda-2611-b1e6-4e912a17f5bb@levkowetz.com> <20190510065425.iy74lntsbeeakjeg@miek.nl> <98223d05-21ec-e914-046d-30c9dcb0a695@levkowetz.com> <20190510120244.dl2sg3qopbb4qd4b@miek.nl> <1b53c89f-6e5b-d009-5d6c-b672bdd02267@levkowetz.com> In-Reply-To: <1b53c89f-6e5b-d009-5d6c-b672bdd02267@levkowetz.com> --Daf9dKNCj2DNW84j7wqG1NkqaXFoMtTnI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2019-05-10 15:03, Henrik Levkowetz wrote: > Hi Miek, >=20 > On 2019-05-10 14:02, Miek Gieben wrote: >> [ Quoting in "Re: [xml2rfc-dev] docName?..." ] >>>No, the docName should not change to a number; the docName is used to = add >>>metadata about the draft from which an RFC is derived when writing a v= 3 >>>RFC in html format, and to insert the draft name when writing draft ou= tput. >>> >>>>> Also because there is a number attribute >>>>> (https://tools.ietf.org/html/rfc7991#section-2.45.7), which I added= eons >>>>> ago because xml2rfc complained; maybe that can be removed now (beca= use >>>>> its deprecated) ? >>> >>>No, as Julian indicates, follow 7749 with respect to metadata. The nu= mber >>>still indicates which RFC number is to be generated. >>> >>> Henrik >>=20 >> Ok, thanks for the info; I'll make those changes. >>=20 >> One more question if you have docName will xml2rfc; will this work as = well: >>=20 >> Warning: Expected a with rel=3D'prev' providing the datatracker= url for the origin draft. >=20 > The v2v3 converter inserts a with rel=3D'prev' if docName is giv= en; > for v3 xml you should set that. I think, however, that this warning sh= ould > more correctly be a note or comment. No, I'm wrong. It should be at least a warning, possibly an error. This= is covered in https://tools.ietf.org/html/rfc7998#section-5.6.3 . This is emitted only in RFC production mode. Henrik --Daf9dKNCj2DNW84j7wqG1NkqaXFoMtTnI-- --csfIuxjiWv5b6lmpVlgmohK7tFSMiLdXn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlzVeBwACgkQTptXS4+7 FxqI2w//Sp1R4B0M5u4DaUQqrk9mMCWnvdRZORrlBJDTOxwAzbjO01RUmqN8YGdN F+BDfZMeZMij/iOUZxoB238nNoiXCU9jg2wYS6t+VIPlleOtdtqrWvDwRsfTrWdv Bkm1IlWA9eKr5neps7QJJZ2P2PEA75P69c4SNTrEMUIzYFDAMLARBtu/o4d5RBDQ uHVtIyNXRqHj5oxaOmE7SZBT64suS/TDJ7lqa+6Ww1EY7U0RPbvhlLIo+hxc8Zdn Ammzk0gNG8duw80jOMfcFn2NrENkvfaZn0TgC4f62ovkxx2dJmyNvT0/5nZfAH9A 7yzJmO33AQNA1bjxFaD5goc21MqSobKv7qprvzQfy80G+NI8stNJJFeOE3FnL8d8 GA2GSYNueeAMLn86tJq5tKkOwRWL5KUrdUv0VOg9tfQ3LIlLQOHCS7vCRNtPu7Ei 7H8iqvHulrSL+y9ah51peWlJGfCBHXggtjemW7uCkW+kkPpcalOWQJHpn+t+PUpw xRXTBqLCC4KKWFVIvPhBDOh5VgASAqp4+qpOLN0uawtcbPyZh2Vy9jI0OYCV8inA O1jewmBY91pcJrIrzDMlnVEf6YH8TgK5ifEXAymYreUKbsL+LwyVsmp+37N1JtVS 847d7sQ/Pn1UOi4xFouUDNX+X+C89eqrgLKB/jznShmNYNsOfjM= =E1Gg -----END PGP SIGNATURE----- --csfIuxjiWv5b6lmpVlgmohK7tFSMiLdXn-- From nobody Fri May 10 06:24:46 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071561201D3 for ; Fri, 10 May 2019 06:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 o7G1tFuic3ri for ; Fri, 10 May 2019 06:24:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777411201A2 for ; Fri, 10 May 2019 06:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557494666; bh=6uHsJ/TnnljLnoqWGfy60KohB/y9WQyvnTfJxbGEpO0=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=B2c9P1IOs6r4MxDLHwZr3zXFqha/8k0Yo9+0cLlU6uv4FP59zAAJGR6+bxkYQWcbv s8z8fDUvvwKoZecWIt5BOwh7OC6/kPj6teR2kOZWSpk2KE2RA6dTV/4Pk0lxgChjQy fwYERexbKDs4VX+pC2geSVce+ZG6gqgb3Zw1ojyU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.148.236]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MdefJ-1gpkct2Dcf-00Zgfx; Fri, 10 May 2019 15:24:26 +0200 To: Henrik Levkowetz , Miek Gieben Cc: XML Developer List References: <20190408214850.fbwdzhza7g4omyvs@miek.nl> <20190509060348.77yjfr3uuff7e67j@miek.nl> <9f6f2abd-5cda-2611-b1e6-4e912a17f5bb@levkowetz.com> <20190510065425.iy74lntsbeeakjeg@miek.nl> <98223d05-21ec-e914-046d-30c9dcb0a695@levkowetz.com> <20190510120244.dl2sg3qopbb4qd4b@miek.nl> <1b53c89f-6e5b-d009-5d6c-b672bdd02267@levkowetz.com> <2d91ecfd-5212-ee60-f82b-c1cae9e1cbc2@levkowetz.com> From: Julian Reschke Message-ID: <2736230b-5846-fb09-56d8-beb376a41548@gmx.de> Date: Fri, 10 May 2019 15:24:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <2d91ecfd-5212-ee60-f82b-c1cae9e1cbc2@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Ct0FA1jJQGX+MnTClSqrmE3hHIYI5gwS3atftV8bR7IRLj6mP89 vmbBQOA03gStpsAfuX+sDUcRjneHcNd2xUm7iML5O7gBdCMb88L+7BxV5pTLhEDDj4aBbnR bsYep4/+3ZGdyR4APC3uWnHvSqmZQQBFNSkH4rKMIp9B5kXa+VFyj+g8NJ8SgL8nlFJsO58 Azw4PpL8DmdlKvqtRAK/w== X-UI-Out-Filterresults: notjunk:1;V03:K0:M/Qk+mJ3t60=:q+XmhAaBZ6XkATYtcKZ8H4 dTF9q/2fTy3mpsBVu/eLeEcuK8GNk01jY9aSVM2wLvb1Gx/Lwlq45Q163VkiKuMvopjSflkQ3 cIo412joQkc5IMlqF4nT9PHLv953cVKodaWZw84PLLr6h/cgQL9mUFNLZxShela2OYpxDwWON mchXuA/DbeXp7I3Vzpqp0pBZdYDK6QAFaqTFPqJgjZElWbXTuc8zoasP9lV+wcRFbtwaGvX1I KAk1gwD2UMAtAWF+AGP3oAoKA4HzQXh9oPchrtHBl2OBvum2/mvsRuTCAKwWcj3RQZg5uinPD OSmEf0+j2VFgzlMdBK3QK91wee7+p++IIermiBwglsgivBSATRa90XD20Y68w1X1IPhaJA4JQ hBcOhovmWr+L8Ux7oEfb0Wrrq9IIWK+urWzu4zJBT/iSpMz9cYghP6+O4Uk9r1me5yNWzlZyf gVGLVXrR0p+YTEM5hP8pr4brVG7qBS5Hz5cDrihpApbw//n/cmPWx1PBGAAE6+NGq9M00D4ZO apX6k0KEgGPTWw7HU1Q+Qa7VQ+mWpJ+mkNaUFjzH0UxQGtFEzXG/88t7q0PeWUYUQU668JxAT v2ge0UugNCZkbaqV+oEU1FYi+9VUxci9VNcXDsCQHsPPT2cuncPObhDy5Jt3A5WlVCTRKOZi1 gfgQqznOPrbmNv7Ql0DiKsIVaV7kEfdnj0iLyx5FV05IWPCI7rvJmXkaNQE6pMKRlXEBmlxZp kpgmK5vKzVz11zxkxliBek5LN8rJXehXXU9bF8tfN7TshDLLOqZKwAQoynNB+aGYhpB/Vfxk7 gdlL1viZOAH3dRO6aSJixa4pSkoXZ2ETyNcJFGR1GNYpBBawoiGTX8alNYywV80usxbrVO65/ Hv9CazoIQTNZxmgXHX5Zg+ERCQAYow6+KDe2pzm5G5acejl1LV7tXLOENqXEgkYHqelGOZ0FR uOSUprKWLXA== Archived-At: Subject: Re: [xml2rfc-dev] docName? X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 13:24:46 -0000 On 10.05.2019 15:09, Henrik Levkowetz wrote: > On 2019-05-10 15:03, Henrik Levkowetz wrote: >> Hi Miek, >> >> On 2019-05-10 14:02, Miek Gieben wrote: >>> [ Quoting in "Re: [xml2rfc-dev] docName?..." ] >>>> No, the docName should not change to a number; the docName is used to= add >>>> metadata about the draft from which an RFC is derived when writing a = v3 >>>> RFC in html format, and to insert the draft name when writing draft o= utput. >>>> >>>>>> Also because there is a number attribute >>>>>> (https://tools.ietf.org/html/rfc7991#section-2.45.7), which I added= eons >>>>>> ago because xml2rfc complained; maybe that can be removed now (beca= use >>>>>> its deprecated) ? >>>> >>>> No, as Julian indicates, follow 7749 with respect to metadata. The n= umber >>>> still indicates which RFC number is to be generated. >>>> >>>> Henrik >>> >>> Ok, thanks for the info; I'll make those changes. >>> >>> One more question if you have docName will xml2rfc; will this work as = well: >>> >>> Warning: Expected a with rel=3D'prev' providing the datatracker= url for the origin draft. >> >> The v2v3 converter inserts a with rel=3D'prev' if docName is giv= en; >> for v3 xml you should set that. I think, however, that this warning sh= ould >> more correctly be a note or comment. > > No, I'm wrong. It should be at least a warning, possibly an error. Thi= s is > covered in https://tools.ietf.org/html/rfc7998#section-5.6.3 . This is > emitted only in RFC production mode. ...but see . From nobody Fri May 10 08:46:49 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8069012016D for ; Fri, 10 May 2019 08:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 gHAHFqZQN8h3 for ; Fri, 10 May 2019 08:46:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E976B120139 for ; Fri, 10 May 2019 08:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557503164; bh=G035KAwjcB8BJOs9PE5Sh1mYTCtfBLWlXJL20Rf/Sms=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=cyX9RivWqEm7d+vx9aA24el/i+d4fRttU+YSN9K5wFYLNAUEpfmZXdKkHbPL3vbLk eX4HO0DD8a2uIX3hpawTq40xdKI2TZjz7KF8BDTsgBgfDvdMIjrkaaOfV42e30fRWx 53dNxH07mQ8gi5FtNf7mazucyRVTmG0Q9Z7zZCsc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.148.236]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LyB6P-1gbIRV1GFR-015WyG; Fri, 10 May 2019 17:46:04 +0200 To: Henrik Levkowetz , XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> From: Julian Reschke Message-ID: <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> Date: Fri, 10 May 2019 17:46:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:yR8Zy7M/goWTLEtJ+po1RhgqZ8OBE3XvO1V0alrkF6MMOF8fqBU 1cn6pnPy3uSPJjqn8g5NFGWaptVG2Md97XjxM9x6DkbMeHW1d/nooMvejCuUdmP3IFMja6w +n84DmvEeWQ6jIf2oCwg2JhVZ3X7V/xfqR2L0+lkLg0bgIqqcnRqlZzgoukTijTNL7Oco61 TQdhJCEjE/e5ciPJR+oVA== X-UI-Out-Filterresults: notjunk:1;V03:K0:vwcqOenX9pk=:b3JsJsT1UUIdvrrDcNMHG6 og3Gc6nswxTb7E3LaqCLsKD9wehnx9XHCP3nxpRE6gSy5aYWrp0HYb9hbRv7XttB4liiTJdaJ gjoKqZuQbfAYoWOsimjuJZgTfpXVDJGPXU5vW2zSpYr9MxKwERq+16fQa7oAB1IMu8QOn7Dr5 kq9JP7EKcFnTNBFWSZuIrsJ1rPxBF77tVxX6eWCegNlIQ+MqcvSBr5XfFpp8maCLDptud7TIv iMUkLkft760qVc5cCuyoZ3vHJghSHVkVbAUfALcu8Wa34ZldXXJFFsPUPbCssBcGc9LEZ3n1s Uet57j0306o3lehuOmWfdsSFSh/RSaW+oYpXdN3jW2D/90mf/cUg8ujVb/5QXA27UobmIqehd eCffV4LFmZeb3P219Uyxe/7WYboXnsz+3XzIq9QsrKFw0ac3+zc0T+XHd82DOdrrh6dpayaSH tyFVq37iySJ3zU6zEZ/CnqxgIZQG0MPqpEhL2XYLm33G8tqnk7gJrN4s+HL/PtRzVw0Rxuewi 7aJyyEHko/5BitRhnGGdXCnuKYDoHkav7EZiwz9h5cV9FZA6L8Vl12Vd0E9oUUGxbkiw30Imw lvne90VEERqscGvKqrcMNZfuRJ6FGhzTAk5s9XP+Gx0vQ+aNj+M+6vnefiLN/H4X7NDE8CE5G ZDYjh56B27YjfEvWtXTKW2z+tIeTXnQA84u+omPoGn3FENYGqprkLU0xtLs/DrkPpPicAi7qu txMQUkC6epp+o+MnU5pwnha7527dnaGYEk93rDo5F6NwwHFQ9/XAmBIuCf9eslBS7DfpIGyum yntY8ZOQIw7MxhCJ8uJ6+nxUy5XeFKH30MbNF41jQy/r4OAWnGzFpEscER/l2Rav0u9WORGmH sLRhFbQD+GQ1zqEMkbLDl3friUzs4s+YD+RbDYnIFGOcg4WRAh/Q5tFfSaJV+FyhVKr/D3Lyz +niphz8Wg9g== Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 15:46:48 -0000 On 10.05.2019 12:00, Henrik Levkowetz wrote: > > > On 2019-05-10 11:38, Julian Reschke wrote: >> On 10.05.2019 11:25, Henrik Levkowetz wrote: >>> ... >>>> Yes. What makes you think it's not? >>> >>> When did v2 get support for handling both a 'src' attribute and textua= l >>> content in ? >>> ... >> >> For at least ten years, I'd say. >> >> Excerpt from rfc5598.xml, dated July 2009: >> >>> >> align=3D"center" >>> alt=3D"[ User, MHS, User Service Model ]" >>> name=3D"Basic Internet Mail Service Model" >>> src=3D"email-arch-fig-svcmodel.png" >>> type=3D"image/png"> >>> >> +--------+ >>> ++=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| Use= r | >>> || +--------+ >>> || ^ >>> +--------+ || +--------+ . >>> | User +=3D=3D++=3D=3D=3D=3D=3D=3D=3D=3D=3D>| User | . >>> +---+----+ || +--------+ . >>> . || ^ . >>> . || +--------+ . . >>> . ++=3D=3D>| User | . . >>> . +--------+ . . >>> . ^ . . >>> . . . . >>> V . . . >>> +---+-----------------+------+------+---+ >>> | . . . . | >>> | .................>. . . | >>> | . . . | >>> | ........................>. . | >>> | . . | >>> | ...............................>. | >>> | | >>> | Message Handling Service (MHS) | >>> +---------------------------------------+ > > And what was the v2 handling of this? If by "v2" you refer to the spec, the answer is over here: . But if you refer to the v2 impl (Python-based), as opposed to the original TCL implementation: I don't know. That RFC was produced with the old tool. But just because the rewritten tool failed to implement that doesn't make the syntax suddenly invalid. Best regards, Julian Best regards, Julian From nobody Fri May 10 09:05:31 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DB5120146 for ; Fri, 10 May 2019 09:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4frHE5_cMk3 for ; Fri, 10 May 2019 09:05:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC2912012A for ; Fri, 10 May 2019 09:05:27 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:54381 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hP81W-0006WP-Dd; Fri, 10 May 2019 09:05:27 -0700 To: Julian Reschke , XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> From: Henrik Levkowetz Message-ID: Date: Fri, 10 May 2019 18:05:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CK1xf1gcdMU60vsSUBJo70eR2VjxrTsh9" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 16:05:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CK1xf1gcdMU60vsSUBJo70eR2VjxrTsh9 Content-Type: multipart/mixed; boundary="mrxalR6M0j9SvKnUe7d76dFom5oxwPx9c"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , XML Developer List Message-ID: Subject: Re: [xml2rfc-dev] feedback References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> In-Reply-To: <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> --mrxalR6M0j9SvKnUe7d76dFom5oxwPx9c Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, On 2019-05-10 17:46, Julian Reschke wrote: > On 10.05.2019 12:00, Henrik Levkowetz wrote: >> >> >> On 2019-05-10 11:38, Julian Reschke wrote: >>> On 10.05.2019 11:25, Henrik Levkowetz wrote: >>>> ... >>>>> Yes. What makes you think it's not? >>>> >>>> When did v2 get support for handling both a 'src' attribute and text= ual >>>> content in ? >>>> ... >>> >>> For at least ten years, I'd say. >>> >>> Excerpt from rfc5598.xml, dated July 2009: >>> >>>> >>> align=3D"center" >>>> alt=3D"[ User, MHS, User Service Model ]" >>>> name=3D"Basic Internet Mail Service Model" >>>> src=3D"email-arch-fig-svcmodel.png" >>>> type=3D"image/png"> >>>> >>> +--------+ >>>> ++=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| U= ser | >>>> || +--------+ >>>> || ^ >>>> +--------+ || +--------+ . >>>> | User +=3D=3D++=3D=3D=3D=3D=3D=3D=3D=3D=3D>| User | . >>>> +---+----+ || +--------+ . >>>> . || ^ . >>>> . || +--------+ . . >>>> . ++=3D=3D>| User | . . >>>> . +--------+ . . >>>> . ^ . . >>>> . . . . >>>> V . . . >>>> +---+-----------------+------+------+---+ >>>> | . . . . | >>>> | .................>. . . | >>>> | . . . | >>>> | ........................>. . | >>>> | . . | >>>> | ...............................>. | >>>> | | >>>> | Message Handling Service (MHS) | >>>> +---------------------------------------+ >> >> And what was the v2 handling of this? >=20 > If by "v2" you refer to the spec, the answer is over here: > . No, Julian. That is not the _spec_ for v2. That is a retroactive=20 best-effort attempt at describing what v2 tools did, and very useful as such. If there is a _spec_ for the vocabulary before RFC 7991, it would be RFC 2629. > But if you refer to the v2 impl (Python-based), as opposed to the > original TCL implementation: I don't know. Ok. > That RFC was produced with > the old tool. Aha? So that's HTML from the TCL tool, not from your XSLT processor? =20 > But just because the rewritten tool failed to implement > that doesn't make the syntax suddenly invalid. No, it doesn't, quite right. Henrik --mrxalR6M0j9SvKnUe7d76dFom5oxwPx9c-- --CK1xf1gcdMU60vsSUBJo70eR2VjxrTsh9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlzVoT4ACgkQTptXS4+7 FxoPJxAAnygQLtCzgBt3BLpwXMzsP8gJXkr3Vzz1wvx/JrcwjADe+Bbc7TNMqnn3 dYTeQV0hX6E+fSrnOmj17P2gDTzhLneffHyEim37AAwPE3xFUGTtBsMPHXYbOBcA hYF0K9rQYjUyeOtxNTNBVzQESMcCGU8mkcMi2il/Tyk9vN4M+NNjRqbKnDspyjVq kBYd+KltwONXONvkgKP/yaqqbyAMz1X2laIkdgslVbSx280JD+lWTThmr11wWFGs Wny/C4xkLJ1c5BEBWfEhdFvUw5ZQKHBKOQucgzuQ58tDavN6lD+FWVE9ojqkmlM8 y8kcGnv9zDjowO8YQpWJ8iQGjkAK0wue4kuin86fHUGjM7DR2gOijekc8BlTobv2 uhrgLjR1/IJUF4Pl/XYGQilo8e+LGz9kSlj5pJPinyw2e0dKvcyowiiD9ckH2NjH H++1RlTeSrVJzyLC/GjIp/ELsQuAgr8tEpk2ULWtxDldNELiuuMVZwawgZnIju+r xJRPiYIK1GiLqxfLI1hT68hvSiu6cMZgncPSeKxc+GftOFZeWsgeZPeHJEpYJF/y lw9nXp1/W17IMt3ErM3N9XF+ILUzMRl7NU6o35PZ79xE+Avi2b8tZxOV412wrUtQ 5T+UQZLE6N/o1xoFUL4ryGK96Q9WIbjcHyy4ilLqI70Fklj7Dk8= =RKoz -----END PGP SIGNATURE----- --CK1xf1gcdMU60vsSUBJo70eR2VjxrTsh9-- From nobody Fri May 10 10:02:52 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B7D120089 for ; Fri, 10 May 2019 10:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 rD6hIEy0gqNK for ; Fri, 10 May 2019 10:02:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3335512000E for ; Fri, 10 May 2019 10:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557507752; bh=lpU6CyMFJlV5xZQ6EaWdFGoSCOxUyvnDcUwfolSjXqg=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=YyTWWD+1j+097im1oVg/yTZg/BqrPZJYp8j75/jxZMlYcyDstpEoYMjeqF0eCFOBL 9xVzxXMZLBF0p0AExMaEtNWttGX1wu+z86i0q7Be+OqXKI+U74630S9mhW2/TSCpPh 2qLBI82buhFBiteifiILCwa3TMqPT9kPeWpYagSk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.148.236]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MbRfv-1griyH1oz3-00btKQ; Fri, 10 May 2019 19:02:32 +0200 To: Henrik Levkowetz , XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> From: Julian Reschke Message-ID: <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> Date: Fri, 10 May 2019 19:02:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:0K9Guf25IMfjY0wejZBIT6zbWTBod9tyl5WJf0ApzL+UIyPXRdU 6SFddo60WoUI5FN+bPZgdo8FYqoNUqL+7PLUTGHhunqM/xvz20ZMb2MQshqmktFrEmAaIGy ATgWUlCOGY4f90YGdKIOJxJ/Op1zFxOWe3zy28A1wOMHEfplsu7+de1ZAPGqKzknHb6CALN 0orQntAdL2KZrP7w3oONQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:9IN1mzPXT08=:VG1MQX0UmkgHjol7786USy 6/Ks5wtnVTHMRm3oelGHyv4SI7U2mdXQ8ZPluH8Gd39G+fW/Ydl81KgkUOJHN3NKC+mdaTBEF VKgnXmYs5arTa1p9UuALNcUcrI2260rjyPt6c52KscQYAjSZw16qA3OAdVC3RgvUTrRBoWjA6 w5o8JsS2aelNnn9+Bk48sZEo134YWBRC5NkBJtxRzxepjkC39gKY05zmvlNNIkbGFxAzbuIHY fn7cf7AvnchtC9x9xzr/G5dnN3ENt/n7iddsl6KPfMwrX7gu42xCKAn1d4HOUDXNu+Egtb5nd g1RFGa0FPkKQroEq8UZMuIPXUQwPtwrpRQBYIxV7fjW5ftJVYvftEnNwdqwwawV9mIv/GCu6w f5j27B8iOTjzJDd8XJP5+YuUI/dJOqiXYmWNxVtt6yICgqg7wmLypa1aD4+fXtfepMVZH3/jl sbOMKCkS9z4LduCEDiWehg5iX2Uhg54mcCtEGw6gd72XxLs32FfLs+CkO1iTqPGHI2opGPhTM +fvJ6O21gXbCBhpe/5lAMRxN2P7DG61wpBVXU6QVLP4jKuwQ9SdcRzC3JSxpQ4X1kR8lM+fCy YM15hRt7tCCFfDwkmq1rO9I7s4EKYZbAxlvbBXkGqq6N3qVmvGW/TJifyOXjc1xp1ReNUAAwc +zQLkyTm9dQmPvV3mO+k/rDaFZqo0kBLxAw6lymlLN8YvNwsD51lAkc9DMiuDKwJYaUe+121G P7e7I/ai/i0oofG2dhdbhkST+RVDwsWq/01GMWfsH11EeydveZlEe5JBXFPCWWQQ5Rxa3j3eg hbRt/c5+YRlZqrmA3Ldma2m2pBBK0cWT4fER/nZYPM6hI8E2wTTyUQ9UCbprDPtHf4SrshbCn K5rhmzZla09tr2KKnZcpLABWt4LmV9ENYrGDeymmARrhXlBl+8Djewl0EeyFjBtJUEmOZpZ7e gg9Wp/qT3oA== Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 17:02:51 -0000 On 10.05.2019 18:05, Henrik Levkowetz wrote: > Hi Julian, > > On 2019-05-10 17:46, Julian Reschke wrote: >> On 10.05.2019 12:00, Henrik Levkowetz wrote: >>> >>> >>> On 2019-05-10 11:38, Julian Reschke wrote: >>>> On 10.05.2019 11:25, Henrik Levkowetz wrote: >>>>> ... >>>>>> Yes. What makes you think it's not? >>>>> >>>>> When did v2 get support for handling both a 'src' attribute and text= ual >>>>> content in ? >>>>> ... >>>> >>>> For at least ten years, I'd say. >>>> >>>> Excerpt from rfc5598.xml, dated July 2009: >>>> >>>>> >>>> align=3D"center" >>>>> alt=3D"[ User, MHS, User Service Model ]" >>>>> name=3D"Basic Internet Mail Service Model" >>>>> src=3D"email-arch-fig-svcmodel.png" >>>>> type=3D"image/png"> >>>>> >>>> +--------+ >>>>> ++=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| = User | >>>>> || +--------+ >>>>> || ^ >>>>> +--------+ || +--------+ . >>>>> | User +=3D=3D++=3D=3D=3D=3D=3D=3D=3D=3D=3D>| User | . >>>>> +---+----+ || +--------+ . >>>>> . || ^ . >>>>> . || +--------+ . . >>>>> . ++=3D=3D>| User | . . >>>>> . +--------+ . . >>>>> . ^ . . >>>>> . . . . >>>>> V . . . >>>>> +---+-----------------+------+------+---+ >>>>> | . . . . | >>>>> | .................>. . . | >>>>> | . . . | >>>>> | ........................>. . | >>>>> | . . | >>>>> | ...............................>. | >>>>> | | >>>>> | Message Handling Service (MHS) | >>>>> +---------------------------------------+ >>> >>> And what was the v2 handling of this? >> >> If by "v2" you refer to the spec, the answer is over here: >> . > > No, Julian. That is not the _spec_ for v2. That is a retroactive > best-effort attempt at describing what v2 tools did, and very useful > as such. If there is a _spec_ for the vocabulary before RFC 7991, it > would be RFC 2629. No. The abstract says: "Version 2 represents the state of the vocabulary (as implemented by several tools and as used by the RFC Editor) around 2014." So this is version 2 of the vocabulary (as spoken in 2014), opposed to v1 (RFC 2629) and v3 (RFC 7991). >> But if you refer to the v2 impl (Python-based), as opposed to the >> original TCL implementation: I don't know. > > Ok. > >> That RFC was produced with >> the old tool. > > Aha? So that's HTML from the TCL tool, not from your XSLT processor? The published PDF was generated using rfc2629toFO.xslt. The published text was published my submitting XML to the RFC Editor, and they presumably used the TCL processor to generate nroff. If your question is whether the TCL version processed artwork/@src: yes, it did (when generating HTML). Even for SVG. Try yourself. > ... Best regards, Julian From nobody Fri May 10 10:17:48 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB92912009E for ; Fri, 10 May 2019 10:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuVngNDa3Bxg for ; Fri, 10 May 2019 10:17:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FAA512000E for ; Fri, 10 May 2019 10:17:43 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:54951 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hP99R-0005if-Gh; Fri, 10 May 2019 10:17:42 -0700 To: Julian Reschke , XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> From: Henrik Levkowetz Message-ID: Date: Fri, 10 May 2019 19:17:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iRE2Ti0e3292r9Dlc6t47AOcmvp0xmiix" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 17:17:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iRE2Ti0e3292r9Dlc6t47AOcmvp0xmiix Content-Type: multipart/mixed; boundary="Ta3W2clDVppOWhEC3Ic7bCjXrKW8RXsHH"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , XML Developer List Message-ID: Subject: Re: [xml2rfc-dev] feedback References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> In-Reply-To: <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> --Ta3W2clDVppOWhEC3Ic7bCjXrKW8RXsHH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2019-05-10 19:02, Julian Reschke wrote: > On 10.05.2019 18:05, Henrik Levkowetz wrote: >> Hi Julian, >> >> On 2019-05-10 17:46, Julian Reschke wrote: >>> On 10.05.2019 12:00, Henrik Levkowetz wrote: >>>> >>>> >>>> On 2019-05-10 11:38, Julian Reschke wrote: >>>>> On 10.05.2019 11:25, Henrik Levkowetz wrote: >>>>>> ... >>>>>>> Yes. What makes you think it's not? >>>>>> >>>>>> When did v2 get support for handling both a 'src' attribute and te= xtual >>>>>> content in ? >>>>>> ... >>>>> >>>>> For at least ten years, I'd say. >>>>> >>>>> Excerpt from rfc5598.xml, dated July 2009: >>>>> >>>>>> >>>>> align=3D"center" >>>>>> alt=3D"[ User, MHS, User Service Model ]" >>>>>> name=3D"Basic Internet Mail Service Model" >>>>>> src=3D"email-arch-fig-svcmodel.png" >>>>>> type=3D"image/png"> >>>>>> >>>>> +--------+ >>>>>> ++=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|= User | >>>>>> || +--------+ >>>>>> || ^ >>>>>> +--------+ || +--------+ . >>>>>> | User +=3D=3D++=3D=3D=3D=3D=3D=3D=3D=3D=3D>| User | . >>>>>> +---+----+ || +--------+ . >>>>>> . || ^ . >>>>>> . || +--------+ . . >>>>>> . ++=3D=3D>| User | . . >>>>>> . +--------+ . . >>>>>> . ^ . . >>>>>> . . . . >>>>>> V . . . >>>>>> +---+-----------------+------+------+---+ >>>>>> | . . . . | >>>>>> | .................>. . . | >>>>>> | . . . | >>>>>> | ........................>. . | >>>>>> | . . | >>>>>> | ...............................>. | >>>>>> | | >>>>>> | Message Handling Service (MHS) | >>>>>> +---------------------------------------+ >>>> >>>> And what was the v2 handling of this? >>> >>> If by "v2" you refer to the spec, the answer is over here: >>> . >> >> No, Julian. That is not the _spec_ for v2. That is a retroactive >> best-effort attempt at describing what v2 tools did, and very useful >> as such. If there is a _spec_ for the vocabulary before RFC 7991, it >> would be RFC 2629. >=20 > No. The abstract says: >=20 > "Version 2 represents the state of the vocabulary (as implemented by > several tools and as used by the RFC Editor) around 2014." As an analysis of the state of things, yes. As a specification, no. What I was attempting to say in the comment above, put in different words, was that we've not had any _specification_ between 2629 and 7991. > So this is version 2 of the vocabulary (as spoken in 2014), opposed to > v1 (RFC 2629) and v3 (RFC 7991). It's a retrospective analysis of the vocabulary, yes. And as you know, we've found discrepancies since it was published. It's not the specification. It's been very useful, but please don't try to represent it as something that it isn't. >>> But if you refer to the v2 impl (Python-based), as opposed to the >>> original TCL implementation: I don't know. >> >> Ok. >> >>> That RFC was produced with >>> the old tool. >> >> Aha? So that's HTML from the TCL tool, not from your XSLT processor? >=20 > The published PDF was generated using rfc2629toFO.xslt. The published > text was published my submitting XML to the RFC Editor, and they > presumably used the TCL processor to generate nroff. I'm asking about the HTML you pointed to. > If your question is whether the TCL version processed artwork/@src: yes= , > it did (when generating HTML). Even for SVG. Try yourself. I don't have a TCL installation which will let me do that. Which is why I'm asking. Henrik --Ta3W2clDVppOWhEC3Ic7bCjXrKW8RXsHH-- --iRE2Ti0e3292r9Dlc6t47AOcmvp0xmiix Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlzVsi0ACgkQTptXS4+7 FxoYzxAAwp0PLeTo6XzLcdCJCgUrARZFrB253nkadoylefGHAJWgKrzNQ6pUprKM 01N72FruA2CChBcSgGMH2y969VPcm1xEuybZfAWoIpVIC29zQ2ZlHfFGo94NqrEy 91YBuPoNsG+Gvn2Z0mHYqQ7RNMJeWk+sLIvVqKMWJgFKLGgVx13gtt9xSj+snQLw CO6Ow0cPMK3gE9M8WyHe2rXB9XpoFjtJ5tdBMuC/FJk2kP4mk25/5shk0i5nBZdb aUW9mSGGt2RkzzUx/8iXkY79ml+2GkhfhhAW0UqWh2PSLQfeAO/LwpDKkOf0dvac Mm7uzuiZinOnnQvlIT1JBpvRupuu6m/B1KpbLDo98kqsangT9e14jUt8v3EUZxT6 1Lcpdj7VJrUTCO1sKAnmnzAEP59U36cVjDIbezDGPFEtzMMGgVL8U5ewOoJ6Y6I7 uI3gRxnL7aQkeW7fdlp+gwgG0AUWUuh4kU3Lful93Q3hgH50cyC7XX+xV18bimEz 2+yCcaH9EmBQ21aSbHADPLpviFNHGNi/f6M/O4NuLT9tRBLsheXiRY3w6ILpAKOV fEsNjozA/PvtvQfbKDnNKST56AjFVPMekKLPCXhe7Mo6bjDGH0GAE3jPwUFxLwmL VqPuya/oCULFuhocdOYs2no6ZZ4NY76W/0XWpuAxl+l3CHm6PZY= =+4GC -----END PGP SIGNATURE----- --iRE2Ti0e3292r9Dlc6t47AOcmvp0xmiix-- From nobody Sat May 11 02:14:36 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF4F120125 for ; Sat, 11 May 2019 02:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 IpCFjLUPlsMl for ; Sat, 11 May 2019 02:14:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC576120103 for ; Sat, 11 May 2019 02:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557566056; bh=9BDjjjSVGhsvpwmfyMIO8z+n2jqFTRQzrBdFP543Ksk=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=FayepZDfBSbX10QYOmpiMZIILG6EAnb5uLNBvk9fPoQXeLbL004scuK9zKzop+iCS fHSEkQqyKBO6f3PwbUh8w1uPO66EGS8/axK2ygIWYDTXurYjNQdVfnDL322OFHvvd5 GDHcBRBd0MKuwEZsjDzmWIvziCnlbQuSNFb/kXn8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.150.128]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MdWO8-1h4YLc0OjM-00PNuF; Sat, 11 May 2019 11:14:16 +0200 To: Henrik Levkowetz , XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> From: Julian Reschke Message-ID: <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de> Date: Sat, 11 May 2019 11:14:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------9B4F2D92D270A8A279112E3E" Content-Language: en-US X-Provags-ID: V03:K1:S46Sdy/tQYp714cGt/ACBMu5fZV6Rmz6r6miF7bXe+M1zJpq6j+ QiF0Dev51dXj5RkatobMVIx65OzjYPrux5o5t8JAMwyDwwiJ3ACXlahED4IpRG2fRy4NBHX zRAnkysUhh/+bLa8IbD7ogjdUfCLtzCnQnqdsjS0Nq5x6ZI3TSpY0uGvEuUWRDpFZIxNk6b gx+rRNN6iTM+76BsZKP5w== X-UI-Out-Filterresults: notjunk:1;V03:K0:464JaaauJzQ=:AD+32LokvkVC0jon3EULZp RLJHhzd9nGZ40hntrhUYUZuHXEe13+ZFaBa0LR1dKL4VHEFhz4it68nBkygryOBQsACd6R0d0 z6ctU7D42oHEgD3au0pVr3EijWXwNwgs8dQ0VfIf8n8zyBeqmJZH+UFpOzmf/ThBBuWhIceVy wh3QDsGjCJmD5qDCEBifDVgUfhctZOFIejDOxzySni6tSLblz7nodRit3kq9tSv7w0S8cq9QJ p7UkkEpGHDvQ/ALxVY5kqtlqRsirld/xK7qR+i4ZenjkZXu5WG8gsb2jG/XZNxEsExZdwzyFB zvZNAG2IZ279+iFIjYiyxUH2K/X/G+lFgtbKblg+fhIo5bn7k7y8ZaWS3DMsFN6I4twf+B7/E gsvEFuPVyO3DUbFrgjO9xkk+iD/eFOayOXt+yu1amb/gO1nkPcabr71+SssxpZcDijFzGhvpV T4LVdz3t+Ilgz/mg4Jcf6VyR8OaVIrIGyN2ZwPIhst9z5uJGoh+NQAZidySSIQjMNgzVK40d3 jcijnSxEDQaqFZI72yUjom3OLuF57uvui96LrjXEAIrIafpfEIbI0U+4+O2c3y6o8LO1GrQSl fkZh7gPsRFzHX+epOknKy9U+ZVkMm1ktEh2lunZHvPuZkqc55J0j4QyqIfki5BvzXkmhECm0j /Q3BzgUYTwizc0nfOd2zPvs9MTdcIyBY+E1V5WIeK0ROAmt9cbfP8Qf5RvyBgxezpa2GJbCCx IZhTsE1anPcDCGF2GvbVxk7Cc13z5Y2NcLd08uiEu2N5V5qmdg/chzJ79gL6oeN9tN0rAa65n 2PFhTWYYfF8/8lCIbvLnQIqtn1Kd2iYZeBYD7rW7Jg5AT/TefqyVVUHxGpR2mTN5+YLOxUGtn sgqwJmglqFSyC1HbdoC0PxmOPF/nP9KZi9sy9vCr8e2rQenok+ntqwe/NGKAq0LDvWRGKoI2j SOIJiW8/jHF5rBpH/BxJhZtVr9aeLRgc= Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2019 09:14:35 -0000 This is a multi-part message in MIME format. --------------9B4F2D92D270A8A279112E3E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 10.05.2019 19:17, Henrik Levkowetz wrote: > ... >>>> If by "v2" you refer to the spec, the answer is over here: >>>> . >>> >>> No, Julian. That is not the _spec_ for v2. That is a retroactive >>> best-effort attempt at describing what v2 tools did, and very useful >>> as such. If there is a _spec_ for the vocabulary before RFC 7991, it >>> would be RFC 2629. >> >> No. The abstract says: >> >> "Version 2 represents the state of the vocabulary (as implemented by >> several tools and as used by the RFC Editor) around 2014." > > As an analysis of the state of things, yes. As a specification, no. > > What I was attempting to say in the comment above, put in different > words, was that we've not had any _specification_ between 2629 and 7991. That doesn't make any sense. Why do you consider RFC 2629 and 7991 as specification, but not 7749? In particular given the fact that a large part of 7991 is a copy if 7749???? >> So this is version 2 of the vocabulary (as spoken in 2014), opposed to >> v1 (RFC 2629) and v3 (RFC 7991). > > It's a retrospective analysis of the vocabulary, yes. And as you know, > we've found discrepancies since it was published. It's not the Example, please. > specification. It's been very useful, but please don't try to represent > it as something that it isn't. It is exactly what I am saying. I don't say it is perfect, but the goal was to specify the vocabulary in use (and implemented), and that's what we did. If this wasn't the case, why does it obsolete RFC 2629??? >>>> But if you refer to the v2 impl (Python-based), as opposed to the >>>> original TCL implementation: I don't know. >>> >>> Ok. >>> >>>> That RFC was produced with >>>> the old tool. >>> >>> Aha? So that's HTML from the TCL tool, not from your XSLT processor? >> >> The published PDF was generated using rfc2629toFO.xslt. The published >> text was published my submitting XML to the RFC Editor, and they >> presumably used the TCL processor to generate nroff. > > I'm asking about the HTML you pointed to. Did I point to HTML? >> If your question is whether the TCL version processed artwork/@src: yes= , >> it did (when generating HTML). Even for SVG. Try yourself. > > I don't have a TCL installation which will let me do that. Which is why > I'm asking. I can't produce an HTML version of RFC 5598 as I don't have the PNG files. I can run the code an a simple example. See attachments. Best regards, Julian --------------9B4F2D92D270A8A279112E3E Content-Type: text/html; charset=UTF-8; name="artwork-test.xml2rfc.html" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="artwork-test.xml2rfc.html" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1s IGxhbmc9ImVuIj48aGVhZD48dGl0bGU+VGVzdHMgZm9yIGFydHdvcms8L3RpdGxlPgo8bWV0 YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNl dD11dGYtOCI+CjxtZXRhIG5hbWU9ImRlc2NyaXB0aW9uIiBjb250ZW50PSJUZXN0cyBmb3Ig YXJ0d29yayI+CjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0ieG1sMnJmYyB2MS4z N3ByZTEgKGh0dHA6Ly94bWwucmVzb3VyY2Uub3JnLykiPgo8c3R5bGUgdHlwZT0ndGV4dC9j c3MnPjwhLS0KICAgICAgICBib2R5IHsKICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiB2 ZXJkYW5hLCBjaGFyY29hbCwgaGVsdmV0aWNhLCBhcmlhbCwgc2Fucy1zZXJpZjsKICAgICAg ICAgICAgICAgIGZvbnQtc2l6ZTogc21hbGw7IGNvbG9yOiAjMDAwOyBiYWNrZ3JvdW5kLWNv bG9yOiAjRkZGOwogICAgICAgICAgICAgICAgbWFyZ2luOiAyZW07CiAgICAgICAgfQogICAg ICAgIGgxLCBoMiwgaDMsIGg0LCBoNSwgaDYgewogICAgICAgICAgICAgICAgZm9udC1mYW1p bHk6IGhlbHZldGljYSwgbW9uYWNvLCAiTVMgU2FucyBTZXJpZiIsIGFyaWFsLCBzYW5zLXNl cmlmOwogICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc3R5bGU6IG5v cm1hbDsKICAgICAgICB9CiAgICAgICAgaDEgeyBjb2xvcjogIzkwMDsgYmFja2dyb3VuZC1j b2xvcjogdHJhbnNwYXJlbnQ7IHRleHQtYWxpZ246IHJpZ2h0OyB9CiAgICAgICAgaDMgeyBj b2xvcjogIzMzMzsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IH0KCiAgICAgICAg dGQuUkZDYnVnIHsKICAgICAgICAgICAgICAgIGZvbnQtc2l6ZTogeC1zbWFsbDsgdGV4dC1k ZWNvcmF0aW9uOiBub25lOwogICAgICAgICAgICAgICAgd2lkdGg6IDMwcHg7IGhlaWdodDog MzBweDsgcGFkZGluZy10b3A6IDJweDsKICAgICAgICAgICAgICAgIHRleHQtYWxpZ246IGp1 c3RpZnk7IHZlcnRpY2FsLWFsaWduOiBtaWRkbGU7CiAgICAgICAgICAgICAgICBiYWNrZ3Jv dW5kLWNvbG9yOiAjMDAwOwogICAgICAgIH0KICAgICAgICB0ZC5SRkNidWcgc3Bhbi5SRkMg ewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6IG1vbmFjbywgY2hhcmNvYWwsIGdlbmV2 YSwgIk1TIFNhbnMgU2VyaWYiLCBoZWx2ZXRpY2EsIHZlcmRhbmEsIHNhbnMtc2VyaWY7CiAg ICAgICAgICAgICAgICBmb250LXdlaWdodDogYm9sZDsgY29sb3I6ICM2NjY7CiAgICAgICAg fQogICAgICAgIHRkLlJGQ2J1ZyBzcGFuLmhvdFRleHQgewogICAgICAgICAgICAgICAgZm9u dC1mYW1pbHk6IGNoYXJjb2FsLCBtb25hY28sIGdlbmV2YSwgIk1TIFNhbnMgU2VyaWYiLCBo ZWx2ZXRpY2EsIHZlcmRhbmEsIHNhbnMtc2VyaWY7CiAgICAgICAgICAgICAgICBmb250LXdl aWdodDogbm9ybWFsOyB0ZXh0LWFsaWduOiBjZW50ZXI7IGNvbG9yOiAjRkZGOwogICAgICAg IH0KCiAgICAgICAgdGFibGUuVE9DYnVnIHsgd2lkdGg6IDMwcHg7IGhlaWdodDogMTVweDsg fQogICAgICAgIHRkLlRPQ2J1ZyB7CiAgICAgICAgICAgICAgICB0ZXh0LWFsaWduOiBjZW50 ZXI7IHdpZHRoOiAzMHB4OyBoZWlnaHQ6IDE1cHg7CiAgICAgICAgICAgICAgICBjb2xvcjog I0ZGRjsgYmFja2dyb3VuZC1jb2xvcjogIzkwMDsKICAgICAgICB9CiAgICAgICAgdGQuVE9D YnVnIGEgewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6IG1vbmFjbywgY2hhcmNvYWws IGdlbmV2YSwgIk1TIFNhbnMgU2VyaWYiLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWY7CiAgICAg ICAgICAgICAgICBmb250LXdlaWdodDogYm9sZDsgZm9udC1zaXplOiB4LXNtYWxsOyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7CiAgICAgICAgICAgICAgICBjb2xvcjogI0ZGRjsgYmFja2dy b3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7CiAgICAgICAgfQoKICAgICAgICB0ZC5oZWFkZXIg ewogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6IGFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogeC1zbWFsbDsKICAgICAgICAgICAgICAgIHZlcnRpY2FsLWFs aWduOiB0b3A7IHdpZHRoOiAzMyU7CiAgICAgICAgICAgICAgICBjb2xvcjogI0ZGRjsgYmFj a2dyb3VuZC1jb2xvcjogIzY2NjsKICAgICAgICB9CiAgICAgICAgdGQuYXV0aG9yIHsgZm9u dC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc2l6ZTogeC1zbWFsbDsgbWFyZ2luLWxlZnQ6IDRlbTsg fQogICAgICAgIHRkLmF1dGhvci10ZXh0IHsgZm9udC1zaXplOiB4LXNtYWxsOyB9CgogICAg ICAgIC8qIGluZm8gY29kZSBmcm9tIFNhbnRhS2xhdXNzIGF0IGh0dHA6Ly93d3cubWFkYWJv dXRzdHlsZS5jb20vdG9vbHRpcDIuaHRtbCAqLwogICAgICAgIGEuaW5mbyB7CiAgICAgICAg ICAgICAgICAvKiBUaGlzIGlzIHRoZSBrZXkuICovCiAgICAgICAgICAgICAgICBwb3NpdGlv bjogcmVsYXRpdmU7CiAgICAgICAgICAgICAgICB6LWluZGV4OiAyNDsKICAgICAgICAgICAg ICAgIHRleHQtZGVjb3JhdGlvbjogbm9uZTsKICAgICAgICB9CiAgICAgICAgYS5pbmZvOmhv dmVyIHsKICAgICAgICAgICAgICAgIHotaW5kZXg6IDI1OwogICAgICAgICAgICAgICAgY29s b3I6ICNGRkY7IGJhY2tncm91bmQtY29sb3I6ICM5MDA7CiAgICAgICAgfQogICAgICAgIGEu aW5mbyBzcGFuIHsgZGlzcGxheTogbm9uZTsgfQogICAgICAgIGEuaW5mbzpob3ZlciBzcGFu LmluZm8gewogICAgICAgICAgICAgICAgLyogVGhlIHNwYW4gd2lsbCBkaXNwbGF5IGp1c3Qg b24gOmhvdmVyIHN0YXRlLiAqLwogICAgICAgICAgICAgICAgZGlzcGxheTogYmxvY2s7CiAg ICAgICAgICAgICAgICBwb3NpdGlvbjogYWJzb2x1dGU7CiAgICAgICAgICAgICAgICBmb250 LXNpemU6IHNtYWxsZXI7CiAgICAgICAgICAgICAgICB0b3A6IDJlbTsgbGVmdDogLTVlbTsg d2lkdGg6IDE1ZW07CiAgICAgICAgICAgICAgICBwYWRkaW5nOiAycHg7IGJvcmRlcjogMXB4 IHNvbGlkICMzMzM7CiAgICAgICAgICAgICAgICBjb2xvcjogIzkwMDsgYmFja2dyb3VuZC1j b2xvcjogI0VFRTsKICAgICAgICAgICAgICAgIHRleHQtYWxpZ246IGxlZnQ7CiAgICAgICAg fQoKICAgICAgICBhIHsgZm9udC13ZWlnaHQ6IGJvbGQ7IH0KICAgICAgICBhOmxpbmsgICAg eyBjb2xvcjogIzkwMDsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IH0KICAgICAg ICBhOnZpc2l0ZWQgeyBjb2xvcjogIzYzMzsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJl bnQ7IH0KICAgICAgICBhOmFjdGl2ZSAgeyBjb2xvcjogIzYzMzsgYmFja2dyb3VuZC1jb2xv cjogdHJhbnNwYXJlbnQ7IH0KCiAgICAgICAgcCB7IG1hcmdpbi1sZWZ0OiAyZW07IG1hcmdp bi1yaWdodDogMmVtOyB9CiAgICAgICAgcC5jb3B5cmlnaHQgeyBmb250LXNpemU6IHgtc21h bGw7IH0KICAgICAgICBwLnRvYyB7IGZvbnQtc2l6ZTogc21hbGw7IGZvbnQtd2VpZ2h0OiBi b2xkOyBtYXJnaW4tbGVmdDogM2VtOyB9CiAgICAgICAgdGFibGUudG9jIHsgbWFyZ2luOiAw IDAgMCAzZW07IHBhZGRpbmc6IDA7IGJvcmRlcjogMDsgdmVydGljYWwtYWxpZ246IHRleHQt dG9wOyB9CiAgICAgICAgdGQudG9jIHsgZm9udC1zaXplOiBzbWFsbDsgZm9udC13ZWlnaHQ6 IGJvbGQ7IHZlcnRpY2FsLWFsaWduOiB0ZXh0LXRvcDsgfQoKICAgICAgICBvbC50ZXh0IHsg bWFyZ2luLWxlZnQ6IDJlbTsgbWFyZ2luLXJpZ2h0OiAyZW07IH0KICAgICAgICB1bC50ZXh0 IHsgbWFyZ2luLWxlZnQ6IDJlbTsgbWFyZ2luLXJpZ2h0OiAyZW07IH0KICAgICAgICBsaSAg ICAgIHsgbWFyZ2luLWxlZnQ6IDNlbTsgfQoKICAgICAgICAvKiBSRkMtMjYyOSA8c3Bhbng+ cyBhbmQgPGFydHdvcms+cy4gKi8KICAgICAgICBlbSAgICAgeyBmb250LXN0eWxlOiBpdGFs aWM7IH0KICAgICAgICBzdHJvbmcgeyBmb250LXdlaWdodDogYm9sZDsgfQogICAgICAgIGRm biAgICB7IGZvbnQtd2VpZ2h0OiBib2xkOyBmb250LXN0eWxlOiBub3JtYWw7IH0KICAgICAg ICBjaXRlICAgeyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXN0eWxlOiBub3JtYWw7IH0K ICAgICAgICB0dCAgICAgeyBjb2xvcjogIzAzNjsgfQogICAgICAgIHR0LCBwcmUsIHByZSBk Zm4sIHByZSBlbSwgcHJlIGNpdGUsIHByZSBzcGFuIHsKICAgICAgICAgICAgICAgIGZvbnQt ZmFtaWx5OiAiQ291cmllciBOZXciLCBDb3VyaWVyLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTog c21hbGw7CiAgICAgICAgfQogICAgICAgIHByZSB7CiAgICAgICAgICAgICAgICB0ZXh0LWFs aWduOiBsZWZ0OyBwYWRkaW5nOiA0cHg7CiAgICAgICAgICAgICAgICBjb2xvcjogIzAwMDsg YmFja2dyb3VuZC1jb2xvcjogI0NDQzsKICAgICAgICB9CiAgICAgICAgcHJlIGRmbiAgeyBj b2xvcjogIzkwMDsgfQogICAgICAgIHByZSBlbSAgIHsgY29sb3I6ICM2NkY7IGJhY2tncm91 bmQtY29sb3I6ICNGRkM7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IH0KICAgICAgICBwcmUgLmtl eSB7IGNvbG9yOiAjMzNDOyBmb250LXdlaWdodDogYm9sZDsgfQogICAgICAgIHByZSAuaWQg IHsgY29sb3I6ICM5MDA7IH0KICAgICAgICBwcmUgLnN0ciB7IGNvbG9yOiAjMDAwOyBiYWNr Z3JvdW5kLWNvbG9yOiAjQ0ZGOyB9CiAgICAgICAgcHJlIC52YWwgeyBjb2xvcjogIzA2Njsg fQogICAgICAgIHByZSAucmVwIHsgY29sb3I6ICM5MDk7IH0KICAgICAgICBwcmUgLm90aCB7 IGNvbG9yOiAjMDAwOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkNGOyB9CiAgICAgICAgcHJlIC5l cnIgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkNDOyB9CgogICAgICAgIC8qIFJGQy0yNjI5IDx0 ZXh0dGFibGU+cy4gKi8KICAgICAgICB0YWJsZS5hbGwsIHRhYmxlLmZ1bGwsIHRhYmxlLmhl YWRlcnMsIHRhYmxlLm5vbmUgewogICAgICAgICAgICAgICAgZm9udC1zaXplOiBzbWFsbDsg dGV4dC1hbGlnbjogY2VudGVyOyBib3JkZXItd2lkdGg6IDJweDsKICAgICAgICAgICAgICAg IHZlcnRpY2FsLWFsaWduOiB0b3A7IGJvcmRlci1jb2xsYXBzZTogY29sbGFwc2U7CiAgICAg ICAgfQogICAgICAgIHRhYmxlLmFsbCwgdGFibGUuZnVsbCB7IGJvcmRlci1zdHlsZTogc29s aWQ7IGJvcmRlci1jb2xvcjogYmxhY2s7IH0KICAgICAgICB0YWJsZS5oZWFkZXJzLCB0YWJs ZS5ub25lIHsgYm9yZGVyLXN0eWxlOiBub25lOyB9CiAgICAgICAgdGggewogICAgICAgICAg ICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7IGJvcmRlci1jb2xvcjogYmxhY2s7CiAgICAgICAg ICAgICAgICBib3JkZXItd2lkdGg6IDJweCAycHggM3B4IDJweDsKICAgICAgICB9CiAgICAg ICAgdGFibGUuYWxsIHRoLCB0YWJsZS5mdWxsIHRoIHsgYm9yZGVyLXN0eWxlOiBzb2xpZDsg fQogICAgICAgIHRhYmxlLmhlYWRlcnMgdGggeyBib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBz b2xpZCBub25lOyB9CiAgICAgICAgdGFibGUubm9uZSB0aCB7IGJvcmRlci1zdHlsZTogbm9u ZTsgfQogICAgICAgIHRhYmxlLmFsbCB0ZCB7CiAgICAgICAgICAgICAgICBib3JkZXItc3R5 bGU6IHNvbGlkOyBib3JkZXItY29sb3I6ICMzMzM7CiAgICAgICAgICAgICAgICBib3JkZXIt d2lkdGg6IDFweCAycHg7CiAgICAgICAgfQogICAgICAgIHRhYmxlLmZ1bGwgdGQsIHRhYmxl LmhlYWRlcnMgdGQsIHRhYmxlLm5vbmUgdGQgeyBib3JkZXItc3R5bGU6IG5vbmU7IH0KCiAg ICAgICAgaHIgeyBoZWlnaHQ6IDFweDsgfQogICAgICAgIGhyLmluc2VydCB7CiAgICAgICAg ICAgICAgICB3aWR0aDogODAlOyBib3JkZXItc3R5bGU6IG5vbmU7IGJvcmRlci13aWR0aDog MDsKICAgICAgICAgICAgICAgIGNvbG9yOiAjQ0NDOyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0ND OwogICAgICAgIH0KLS0+PC9zdHlsZT4KPC9oZWFkPgo8Ym9keT4KPHRhYmxlIHN1bW1hcnk9 ImxheW91dCIgd2lkdGg9IjY2JSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNw YWNpbmc9IjAiPjx0cj48dGQ+PHRhYmxlIHN1bW1hcnk9ImxheW91dCIgd2lkdGg9IjEwMCUi IGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjIiIGNlbGxzcGFjaW5nPSIxIj4KPHRyPjx0ZCBj bGFzcz0iaGVhZGVyIj5OZXR3b3JrIFdvcmtpbmcgR3JvdXA8L3RkPjx0ZCBjbGFzcz0iaGVh ZGVyIj5KLiBSZXNjaGtlPC90ZD48L3RyPgo8dHI+PHRkIGNsYXNzPSJoZWFkZXIiPkludGVy bmV0LURyYWZ0PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+TWF5IDExLCAyMDE5PC90ZD48L3Ry Pgo8dHI+PHRkIGNsYXNzPSJoZWFkZXIiPkludGVuZGVkIHN0YXR1czogSW5mb3JtYXRpb25h bDwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPiZuYnNwOzwvdGQ+PC90cj4KPHRyPjx0ZCBjbGFz cz0iaGVhZGVyIj5FeHBpcmVzOiBOb3ZlbWJlciAxMiwgMjAxOTwvdGQ+PHRkIGNsYXNzPSJo ZWFkZXIiPiZuYnNwOzwvdGQ+PC90cj4KPC90YWJsZT48L3RkPjwvdHI+PC90YWJsZT4KPGgx PjxiciAvPlRlc3RzIGZvciBhcnR3b3JrPGJyIC8+YXJ0d29yay10ZXN0PC9oMT4KCjxoMz5T dGF0dXMgb2YgdGhpcyBNZW1vPC9oMz4KPHA+ClRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3Vi bWl0dGVkICBpbiBmdWxsCmNvbmZvcm1hbmNlIHdpdGggdGhlIHByb3Zpc2lvbnMgb2YgQkNQ Jm5ic3A7NzggYW5kIEJDUCZuYnNwOzc5LjwvcD4KPHA+CkludGVybmV0LURyYWZ0cyBhcmUg d29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nClRhc2sgRm9y Y2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRl CndvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1 cnJlbnQKSW50ZXJuZXQtRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kcmFmdHMvY3VycmVudC8uPC9wPgo8cD4KSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCmFuZCBtYXkgYmUg dXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQg YW55IHRpbWUuCkl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBh cyByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZQp0aGVtIG90aGVyIHRoYW4gYXMgJmxk cXVvO3dvcmsgaW4gcHJvZ3Jlc3MuJnJkcXVvOzwvcD4KPHA+ClRoaXMgSW50ZXJuZXQtRHJh ZnQgd2lsbCBleHBpcmUgb24gTm92ZW1iZXIgMTIsIDIwMTkuPC9wPgoKPGgzPkNvcHlyaWdo dCBOb3RpY2U8L2gzPgo8cD4KQ29weXJpZ2h0IChjKSAyMDE5IElFVEYgVHJ1c3QgYW5kIHRo ZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCmRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmln aHRzIHJlc2VydmVkLjwvcD4KPHA+ClRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1Ag NzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJ RVRGIERvY3VtZW50cwooaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBp biBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4g IFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCmNhcmVmdWxseSwgYXMgdGhleSBkZXNj cmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdAp0byB0aGlz IGRvY3VtZW50LiBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVu dCBtdXN0CmluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJl ZCBpbiBTZWN0aW9uIDQuZSBvZgp0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJl IHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlm aWVkIEJTRCBMaWNlbnNlLjwvcD4KCjxhIG5hbWU9ImFuY2hvcjEiPjwvYT48YnIgLz48aHIg Lz4KPGEgbmFtZT0icmZjLnNlY3Rpb24uMSI+PC9hPjxoMz4xLiZuYnNwOwpUZXN0PC9oMz4K PGRpdj48aW1nIHNyYz0icmVjdC5zdmciIGFsdD0iW2dyYXBoaWMgaW1hZ2UgZXF1aXZhbGVu dCB0byB0aGUgdGV4dHVhbCBjb250ZW50IGJlbG93XSIgLz48L2Rpdj4KPGRpdiBzdHlsZT0n ZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDogM2VtOyBtYXJnaW4tcmln aHQ6IGF1dG8nPjxwcmU+CistKwp8IHwKKy0rPC9wcmU+PC9kaXY+PC9kaXY+Cgo8YSBuYW1l PSJyZmMuYXV0aG9ycyI+PC9hPjxiciAvPjxociAvPgo8aDM+QXV0aG9yJ3MgQWRkcmVzczwv aDM+Cjx0YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxs c3BhY2luZz0iMCI+Cjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPgo8 dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5KdWxpYW4gUmVzY2hrZTwvdGQ+PC90cj4KPC90YWJs ZT4KPC9ib2R5PjwvaHRtbD4K --------------9B4F2D92D270A8A279112E3E Content-Type: text/xml; name="artwork-test.xml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="artwork-test.xml" Tests for artwork
+-+ | | +-+
--------------9B4F2D92D270A8A279112E3E-- From nobody Sat May 11 02:18:43 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742311200E3 for ; Sat, 11 May 2019 02:18:41 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 vGJwkPK5LrUr for ; Sat, 11 May 2019 02:18:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FABB12006F for ; Sat, 11 May 2019 02:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557566307; bh=yxOkMUED6r2Mq04duHpUUEBqlzkGAlr/ORNHqyWxFag=; h=X-UI-Sender-Class:Subject:From:To:References:Date:In-Reply-To; b=SPX3vrk0oe2/kWGWL1GtFxVqdI6TYVcJKbW58f3H0P54gcvLkpFGIStPPBH4fTpSS fizarDOPkDkb8dxjd/PvFOX+oaczBAsVPnpDGMnQbeQt1B1NMBI4M61bXhSP3uPkny vwrJ0PU7vx1z9F+HpMmLokx4ktcrPnOUd0a9kXZI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.150.128]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MZTqg-1hAcwn0jqg-00WVxh; Sat, 11 May 2019 11:18:27 +0200 From: Julian Reschke To: Henrik Levkowetz , XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de> Message-ID: <2e26b16e-eef5-2413-a2ee-affa46851dbd@gmx.de> Date: Sat, 11 May 2019 11:18:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de> Content-Type: multipart/mixed; boundary="------------9196BB129C73FC03C2ECFEF4" Content-Language: en-US X-Provags-ID: V03:K1:VG6hI3RB5+J1sAbudsCjFz/m3ln3uws3wjZZMFD59vnMa0d0+9E IRePQ6vStaT72OC333gSVOdWmkQTN6Cgv9uwzKrEZPIj4DsaBWbaAYfl7/g9YlwlfChOUVU gUlRWBNGY/TNgVOIxgQWAlFxY+siw7LM1ynYnttb4utlZYCSs0sBASUDZ9rqA3o6dfEA3uv GYB5RDdHZ+Nfly/CifLYw== X-UI-Out-Filterresults: notjunk:1;V03:K0:cLkey0+IhO0=:VvCTozflTz0jI5L90lyLi1 ZUtg4bAyHgbNgk41vRgDYD8h85xRtLCBy12QjGW3FXzvISXPTrUvY+lE4ojJsm1Fqk5/4zSOY eU9e8f7D1vFjNQtOIdwJBn0LfThx0TGmbii/zXoZrNII/yyjF1/foOr3QLkFFxqJh7pHXUm4R sgqXgws11+2ZMj1x7tmCoPnZ/CqTKuOVLehh+6NQUOsulyXEUlskje04sHYmtSc6J73hNtaQh RuV0kkEwAHMEDDdc5kAzmMGqlXkFdgFO9Lz7wncgEbnQOl4t6bUNWJ+ilQHJx3lOuEIR1EF4m Ngk6RLYgGEieRQiW9ftsrkncN1c67noPT5f3T2dC7OWXK/gUwg+f4iXTcQB/hJB1KG7RFu0ky AB7DnEJY2epTdq+5brhwU5NS6Zo/apeM2DhHP0AVTXVg9sC7tjJcoi5qpWRXB67dneOzwv3Iq i1gJO1Lp6lvDKW3ARjMZuVY/CaKyxCJwo31FIi4ter5BZ5hLU2idytynrF6QHl5uLVzOCJkgI p93HpQFjvjjsOCyWCUWkMVXaORXOO7OJG2ZZEuNmphiPW6Md/dGZ1Asx2Am05a6jUzzxKx/5x p9ykp+qf+eqyDbguSsh2DWbh9+ftBSI7pnqjNqqH7xuQ7m5YpND4YlVUiqTtu+pKnegxVcEZx NoB0yTMjVLQ996aOt8QO60OH06kIkQtkGXchudHzDqF+NI0xAtsT37787SjffNmqpnSYmC9x8 QXm2ikEvqCQruhX5Wt3ZTHl60INvyZsqEqN/e7Qmb+I2r+P39pdplBNWgRp45dDSpZaWH4bAL 3c1a8uAyTUFFkb2+ZfKSHuUmlbrQk6f15/iC5n/VTAeRnqoi8UTZVudB8cgU7mEcz++tRjGZw cvLbvF/zo5y71YMIZCst3mKHQ3m0E1qG/FVKFm1WL8KN/sNNOhjAEbbaBfePvt Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2019 09:18:42 -0000 This is a multi-part message in MIME format. --------------9196BB129C73FC03C2ECFEF4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 11.05.2019 11:14, Julian Reschke wrote: > ... > I can't produce an HTML version of RFC 5598 as I don't have the PNG > files. I can run the code an a simple example. See attachments. > ... And of course I did forgot to attach the external graphics file... :-) Best regards, Julian --------------9196BB129C73FC03C2ECFEF4 Content-Type: image/svg+xml; name="rect.svg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rect.svg" PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPg0KICA8cmVjdCB4PSIx MCIgeT0iMTAiIHdpZHRoPSIzMCIgaGVpZ2h0PSIzMCIgc3Ryb2tlPSJibGFjayIgZmlsbD0i d2hpdGUiIHN0cm9rZS13aWR0aD0iMiIvPg0KPC9zdmc+DQo= --------------9196BB129C73FC03C2ECFEF4-- From nobody Sat May 11 03:15:31 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB221200FD for ; Sat, 11 May 2019 03:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEPXyaNmWLKl for ; Sat, 11 May 2019 03:15:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7228612004F for ; Sat, 11 May 2019 03:15:27 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:62854 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hPP2M-0005SR-91; Sat, 11 May 2019 03:15:26 -0700 To: Julian Reschke , XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de> From: Henrik Levkowetz Message-ID: Date: Sat, 11 May 2019 12:15:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KdPOOX8UOo9i5KVO6FL5MHt7jxwWXTeFu" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2019 10:15:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KdPOOX8UOo9i5KVO6FL5MHt7jxwWXTeFu Content-Type: multipart/mixed; boundary="apa7ec5AV9PIXcGMtVcn5WtFJPvFM9ILf"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , XML Developer List Message-ID: Subject: Re: [xml2rfc-dev] feedback References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de> In-Reply-To: <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de> --apa7ec5AV9PIXcGMtVcn5WtFJPvFM9ILf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2019-05-11 11:14, Julian Reschke wrote: > On 10.05.2019 19:17, Henrik Levkowetz wrote: >> ... >>>>> If by "v2" you refer to the spec, the answer is over here: >>>>> . >>>> >>>> No, Julian. That is not the _spec_ for v2. That is a retroactive >>>> best-effort attempt at describing what v2 tools did, and very useful= >>>> as such. If there is a _spec_ for the vocabulary before RFC 7991, i= t >>>> would be RFC 2629. >>> >>> No. The abstract says: >>> >>> "Version 2 represents the state of the vocabulary (as implemented by >>> several tools and as used by the RFC Editor) around 2014." >> >> As an analysis of the state of things, yes. As a specification, no. >> >> What I was attempting to say in the comment above, put in different >> words, was that we've not had any _specification_ between 2629 and 799= 1. >=20 > That doesn't make any sense. Why do you consider RFC 2629 and 7991 as > specification, but not 7749? In particular given the fact that a large > part of 7991 is a copy if 7749???? I think it's a matter of an understanding of words. A specification is what's written before you build something, it is a controlling document. If the software comes first, and is the controlling factor, what you writ= e is a description. You can't put something into the description that differs from what the already built software does, and then turn around and say that the software doesn't conform. So it's not a specification of what the software should do, it's a description of what the software is already doing. If you intend to build a new instance of the software, then you can say that the description of the old software is to be the specification of th= e new instance. Then you've elevated it to the controlling document for th= e new instance. But it's still just a description of the old instance, not= the specification for it. >>> So this is version 2 of the vocabulary (as spoken in 2014), opposed t= o >>> v1 (RFC 2629) and v3 (RFC 7991). >> >> It's a retrospective analysis of the vocabulary, yes. And as you know= , >> we've found discrepancies since it was published. It's not the >=20 > Example, please. You have the errata, of course, and there are a few things I've mentioned= to you in email over the years. I can go and dig in old emails. Oh, I recall one; xml2rfc already had 'quote-title', but you didn't menti= on that in RFC 7749; as a result, RFC 7991 introduced 'quoteTitle'. >> specification. It's been very useful, but please don't try to represe= nt >> it as something that it isn't. >=20 > It is exactly what I am saying. I don't say it is perfect, but the goal= > was to specify the vocabulary in use (and implemented), and that's what= > we did. The goal was to describe the vocabulary, and that's what you did, to some= extent. > If this wasn't the case, why does it obsolete RFC 2629??? >=20 >>>>> But if you refer to the v2 impl (Python-based), as opposed to the >>>>> original TCL implementation: I don't know. >>>> >>>> Ok. >>>> >>>>> That RFC was produced with >>>>> the old tool. >>>> >>>> Aha? So that's HTML from the TCL tool, not from your XSLT processor= ? >>> >>> The published PDF was generated using rfc2629toFO.xslt. The published= >>> text was published my submitting XML to the RFC Editor, and they >>> presumably used the TCL processor to generate nroff. >> >> I'm asking about the HTML you pointed to. >=20 > Did I point to HTML? I believed you did, but I may have found that on my own. Apologies. >>> If your question is whether the TCL version processed artwork/@src: y= es, >>> it did (when generating HTML). Even for SVG. Try yourself. >> >> I don't have a TCL installation which will let me do that. Which is w= hy >> I'm asking. >=20 > I can't produce an HTML version of RFC 5598 as I don't have the PNG > files. I can run the code an a simple example. See attachments. Ok, so when producing HTML output, the TCL code included both the externa= l graphics pointed at by the "src" attribute _and_ the text conte= nt. (There's another discrepancy for you, by the way.) I'll adjust the v2v3 converter to produce in the v3 output when = it comes across both "src" content and inline content in the v2 input. Henrik --apa7ec5AV9PIXcGMtVcn5WtFJPvFM9ILf-- --KdPOOX8UOo9i5KVO6FL5MHt7jxwWXTeFu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlzWoK8ACgkQTptXS4+7 FxpjDhAAolpvWOHxIdGKKY8Mxfu+r+/DJnQGI/VtrjOG9HvtqRNrPjlfHJU5+vaA 6xdynokUkPD5fBUE8aoI1eyLlZV1KpIHj8r0UCwwB9QvP59/12MsXlTr74JRCUdW GfrXD3RJQS1tSNj/jkqlymAzjoW2R7XZqt5geqITDzlUCjYD1YAgzeyznRPwmQOl zMCRBI7ytN+bO0NBCcA6RFSWMgq8eCbYRRydnS8GKW2yEhRcnCIKKMNCquGESjW2 QRezFA/U9/D4BJI1dCIRRUfNgAhU5tV7uB2VX0KvfcIjAurzpIfSRTmfyGITGheu VuSUb656Knq7g1mKxXQGxMDIhh4mhonoJ19rbqXwUQPv+jVHX6n1Y9RsodXiIcVt i7Lt8/bP/lS6UWvgGk0fdmmuJB66DWInWBzldScHmOQDCULnGWKPbzs+qsnTYrJC d2FlQthiimCLzUS/fjoBcrb2yBEJK8ITdw9a3/0acK+WompPC5TAxeQDm7riP93W QuWQYW4BxqAcir27SrRixhXdSSZtqvEZ0p0DsZHzuA6skREs/Q04uzOUGNR3Zutu 5emWIep6GTTG2IyGT1B57TrFCgitXsJ8ADgm9QLsqwtFJiQyO1jc489xDaKXy7uk TmDeB+ePuuYvzh5tYS4emHpSoZ84QvXIDVg8V44cG16CFwAhgYU= =BMZ7 -----END PGP SIGNATURE----- --KdPOOX8UOo9i5KVO6FL5MHt7jxwWXTeFu-- From nobody Sat May 11 05:27:14 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9F912004E for ; Sat, 11 May 2019 05:27:12 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 qHHCBqRXwgM8 for ; Sat, 11 May 2019 05:27:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657FD120033 for ; Sat, 11 May 2019 05:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557577615; bh=xnL1kUutcVda3ZnRx3J+b3j0VmUYlgAOp6cQC62jOx0=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=XaikCiEIAPvyAI81YwVDTS/sgtAxF+OVhOZF9FuefNTUlXEWjz43iKmfySzc9vcwv d8cglkOqx8oYOhXQqqLpdfUE5s3lY+NjU729j4jPNNelh+fcUZLq0MLIyXGuMRxZPY dmP6Xw7Z1H21brU/QwrvKXS2/hvlvv8DhR0yhqdY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.150.128]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MN5if-1h74l0219Z-00IzFj; Sat, 11 May 2019 14:26:55 +0200 To: Henrik Levkowetz , XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de> From: Julian Reschke Message-ID: Date: Sat, 11 May 2019 14:26:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:KCkVPkAN0emaxKz8Q28Hyzh9ktCUmGhhVMXSD+E7Zvpxx2eiDeF MoQ281Fr5rU/dgIrNk2JcTybXQ8xfLzGsWBqyR7HOm7FrSTF1yNjOR9XNLBMWNNq4aBdBIP yDaDIe6GpWpIAz8Zjrdpt2OApoaVMrSvMxowVxvsIyisAPYPesol/tRVoaqEcNNYzP3H19v 7yxRNjQlmtno+zbOV53TA== X-UI-Out-Filterresults: notjunk:1;V03:K0:GL2WjLabzuA=:aY3DD07WMwqUA4lByzkf4A AEuP1OYnOBAo2kWtuJ1IxQG/7ehRLPP/IAWDsycsLJe470Wsq4l30s53SvAFCJEjryM/0WbCE Wk8qSEYGtFnhCGzCIRZDHbMbHLVstdNmC0zK6ns8b+2KlcSc0nn+PjdYPcpaOVpldJMOyX84K gwiDefmQioVVnMAHs2ERnHSvcAGUac4gwMn5Hk8iqhVz0Q13En3MM5FgpilyCLkvuCm3QT+OU ZTXwuNW4MD0T7wxAlmvXdIuNrCtoMmrmbHt7J07QTGQw78QRLJHY4tgXDRVuwwvVJb5QwdskB fjb+2fSi/T6xUqazxYaeYK1B01PwX2d+fVTDV9SC6W05oBbY9/Jlqe0RHVsYCDcnffNpG1BcK HjHBqgXqvlTsgAmhHUY847mk1nMQXsh7u8XYtYcSkFPfIWAEIeXXH/lYYDWQqkarCc9eKYIsL shzrVP3OqlrfWJ8hVPrzISJqKL11CZDe5e8IOYCfify3Ne6/gh4RNo8RtRChNGYWRJmDmkda4 km65JA5OboDyfd6FgatS7NNO7A994tIHzmbHHyaDs7o/ZlZNnoEg3A2QusZqVGUE833buqfNf 1W+3nKP4WU3fHFVlXLjtZ7KUbgy1zCtdT8Tc9Xv/25J8B2zuGYWhIqhRfUTmcqvv2LH1WBkcE CLhHp6gzFn0bFt1TxvuPb47vxJ+8y6SMIfXAWq8URvzOAhIzSZ3065uPjVxvG1CQQObEjvQe1 BVFmZSqs5Ef+iuxArLpNG12VLa/sec93zd0qG54Va/bkvLumS9ni3B0WJOtfbNz1r+EpzOZxu ErIAIYRzuGjYBGxZV1gPOdQskZkIB+x6yQPgYAcPzLnx9JnT6p5NSkCzrj+L6WQiM4+Olfy7A B8WdBZNuubLxeDgE7o4mmu2JGRsienUkXNdVaTLaZp1+QUegNRROLFEjawACl+sXEdkZSVGlZ lB6qyjAbcDQ== Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2019 12:27:13 -0000 On 11.05.2019 12:15, Henrik Levkowetz wrote: > ... > > I think it's a matter of an understanding of words. A specification is > what's written before you build something, it is a controlling document. > > If the software comes first, and is the controlling factor, what you wri= te > is a description. You can't put something into the description that > differs from what the already built software does, and then turn around > and say that the software doesn't conform. So it's not a specification > of what the software should do, it's a description of what the software > is already doing. > > If you intend to build a new instance of the software, then you can say > that the description of the old software is to be the specification of t= he > new instance. Then you've elevated it to the controlling document for t= he > new instance. But it's still just a description of the old instance, no= t > the specification for it. > ... So the HTTP specification is a description, not a specification? /me shakes head >>>> So this is version 2 of the vocabulary (as spoken in 2014), opposed t= o >>>> v1 (RFC 2629) and v3 (RFC 7991). >>> >>> It's a retrospective analysis of the vocabulary, yes. And as you know= , >>> we've found discrepancies since it was published. It's not the >> >> Example, please. > > You have the errata, of course, and there are a few things I've mentione= d > to you in email over the years. I can go and dig in old emails. > > Oh, I recall one; xml2rfc already had 'quote-title', but you didn't ment= ion > that in RFC 7749; as a result, RFC 7991 introduced 'quoteTitle'. As far as I recall, quote-title was introduced while 7749 was in the works, and we consciously limited it to what was implemented when the work started. We did indeed look at quote-title, found that the name was inconsistent with the remainder of the vocabulary, and picked quoteTitle instead (in 7791). I still don't understand why you just don't fix it in your implementation according to the spec. > ... >>>>> Aha? So that's HTML from the TCL tool, not from your XSLT processor= ? >>>> >>>> The published PDF was generated using rfc2629toFO.xslt. The published >>>> text was published my submitting XML to the RFC Editor, and they >>>> presumably used the TCL processor to generate nroff. >>> >>> I'm asking about the HTML you pointed to. >> >> Did I point to HTML? > > I believed you did, but I may have found that on my own. Apologies. > >>>> If your question is whether the TCL version processed artwork/@src: y= es, >>>> it did (when generating HTML). Even for SVG. Try yourself. >>> >>> I don't have a TCL installation which will let me do that. Which is w= hy >>> I'm asking. >> >> I can't produce an HTML version of RFC 5598 as I don't have the PNG >> files. I can run the code an a simple example. See attachments. > > Ok, so when producing HTML output, the TCL code included both the extern= al > graphics pointed at by the "src" attribute _and_ the text cont= ent. > > (There's another discrepancy for you, by the way.) Good catch. So the TCL code did something weird here (also not what it said it does in = ) > I'll adjust the v2v3 converter to produce in the v3 output when= it > comes across both "src" content and inline content in the v2 input. That's nice but I don't think it's sufficient. This simply is and had been valid input, and there is no reason not to support it in v3. Well, except to justify the introduction of :-) Best regards, Julian From nobody Sat May 11 05:41:07 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F78D12008B for ; Sat, 11 May 2019 05:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VPKJWXlP8ya for ; Sat, 11 May 2019 05:41:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 863C9120026 for ; Sat, 11 May 2019 05:41:05 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:63888 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hPRJH-0002Vb-SA; Sat, 11 May 2019 05:41:05 -0700 To: Julian Reschke , XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de> From: Henrik Levkowetz Message-ID: <0755ffb0-490f-6ade-7526-12c867f3cd79@levkowetz.com> Date: Sat, 11 May 2019 14:40:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KlSD3pc1B1nAbUOB2uldjI7KPO9l2GkRa" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, julian.reschke@gmx.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2019 12:41:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KlSD3pc1B1nAbUOB2uldjI7KPO9l2GkRa Content-Type: multipart/mixed; boundary="ppcJI4brFtbLVnqApbKs9fFgs0k53weuT"; protected-headers="v1" From: Henrik Levkowetz To: Julian Reschke , XML Developer List Message-ID: <0755ffb0-490f-6ade-7526-12c867f3cd79@levkowetz.com> Subject: Re: [xml2rfc-dev] feedback References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de> In-Reply-To: --ppcJI4brFtbLVnqApbKs9fFgs0k53weuT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2019-05-11 14:26, Julian Reschke wrote: > On 11.05.2019 12:15, Henrik Levkowetz wrote: >> ... >> >> I think it's a matter of an understanding of words. A specification i= s >> what's written before you build something, it is a controlling documen= t. >> >> If the software comes first, and is the controlling factor, what you w= rite >> is a description. You can't put something into the description that >> differs from what the already built software does, and then turn aroun= d >> and say that the software doesn't conform. So it's not a specificatio= n >> of what the software should do, it's a description of what the softwar= e >> is already doing. >> >> If you intend to build a new instance of the software, then you can sa= y >> that the description of the old software is to be the specification of= the >> new instance. Then you've elevated it to the controlling document for= the >> new instance. But it's still just a description of the old instance, = not >> the specification for it. >> ... >=20 > So the HTTP specification is a description, not a specification? Could you be slightly more specific? Which document are you talking about? =20 > /me shakes head Interesting approach to what ought to be a reasonable discussion. >>>>> So this is version 2 of the vocabulary (as spoken in 2014), opposed= to >>>>> v1 (RFC 2629) and v3 (RFC 7991). >>>> >>>> It's a retrospective analysis of the vocabulary, yes. And as you kn= ow, >>>> we've found discrepancies since it was published. It's not the >>> >>> Example, please. >> >> You have the errata, of course, and there are a few things I've mentio= ned >> to you in email over the years. I can go and dig in old emails. >> >> Oh, I recall one; xml2rfc already had 'quote-title', but you didn't me= ntion >> that in RFC 7749; as a result, RFC 7991 introduced 'quoteTitle'. >=20 > As far as I recall, quote-title was introduced while 7749 was in the > works, and we consciously limited it to what was implemented when the > work started. So it's a description of the status quo at a particular point in time? > We did indeed look at quote-title, found that the name was inconsistent= > with the remainder of the vocabulary, and picked quoteTitle instead (in= > 7791). >=20 > I still don't understand why you just don't fix it in your > implementation according to the spec. You're asking for something that would break existing xml? The current xml2rfc understands both, and the v2v3 converter converts quote-title to quoteTitle; if you're asking for more, you're asking for intentional breakage. >> ... >>>>>> Aha? So that's HTML from the TCL tool, not from your XSLT process= or? >>>>> >>>>> The published PDF was generated using rfc2629toFO.xslt. The publish= ed >>>>> text was published my submitting XML to the RFC Editor, and they >>>>> presumably used the TCL processor to generate nroff. >>>> >>>> I'm asking about the HTML you pointed to. >>> >>> Did I point to HTML? >> >> I believed you did, but I may have found that on my own. Apologies. >> >>>>> If your question is whether the TCL version processed artwork/@src:= yes, >>>>> it did (when generating HTML). Even for SVG. Try yourself. >>>> >>>> I don't have a TCL installation which will let me do that. Which is= why >>>> I'm asking. >>> >>> I can't produce an HTML version of RFC 5598 as I don't have the PNG >>> files. I can run the code an a simple example. See attachments. >> >> Ok, so when producing HTML output, the TCL code included both the exte= rnal >> graphics pointed at by the "src" attribute _and_ the text co= ntent. >> >> (There's another discrepancy for you, by the way.) >=20 > Good catch. So the TCL code did something weird here (also not what it > said it does in > ) >=20 >> I'll adjust the v2v3 converter to produce in the v3 output wh= en it >> comes across both "src" content and inline content in the v2 input. >=20 > That's nice but I don't think it's sufficient. Ahh, but I think it is. Difference of opinion, here. > This simply is and had been valid input, and there is no reason not to > support it in v3. Well, except to justify the introduction of = :-) So there's a lot of the vocabulary that is marked deprecated. I'll just permit all of that in pure v3 too, then? I understand that you don't like . You've said so repeatedly, an= d it looks as if you can't let it go. I'm fine with you having that opinio= n. Henrik --ppcJI4brFtbLVnqApbKs9fFgs0k53weuT-- --KlSD3pc1B1nAbUOB2uldjI7KPO9l2GkRa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlzWwtgACgkQTptXS4+7 FxpCrQ/+NfiEKSzDAL4m4mD/tpy0MFk3/zcyWZ0n3cco0wMt2uIjjITcFNV0bDMp rTFmKXmDrkW0Ef+ZM0qBeKFVH+OSNyI6Gxowpx7d96jxAtVnfGj0DBRpG9xHFl6y nnyb0uIpPqfHoW3JOxPZjdCqEwwcrhPl8CWJXjIMH1g+x3zxh6o1ckmHHW52R3kC kymXpi1rWMzk/VX0nqz1AaN7emVcJNLPKkM8PDKVH0njPMHIgWV9FM5NYcfoklur C1AI3yq0mNaDRUeePb7mzuh6L+Ib539IXR4PR9GzleMvgVr7iohqJXm6rXYdOAFo +9/ZZHBYocq6rOCXOt0ZlNTw58FN92NveSMKMWb/5fkJZdUsbc0FExq0UyWYSSzj UvKjOKHJt6cl4zBDyCqOI0c5J+X3Lh68wVbxYR2dlLskAf7EbDbtAxaFri3HWMEd CGVhHQ1OjM1pns2WEFnD7fNe0LozNd9VLwDNQLOPHrdG3o/DeWnOjW3uOTJr9kw6 IkP9LX57SHo9AureHUXH6Ap67t/GALRCIyss5kjPdMKsOapy97RomyaTKQdo6ZT+ TjP3P16A0FK5zfq0S/kla3yGT+1oUIOt0a6zLeq/gfOPrc727DXAgEtvbQvmQYET wmNn6o2BvR70RYKgeri51TPBpGrX0rvZhP4eOCuul/Qi8/1pc9o= =pdtc -----END PGP SIGNATURE----- --KlSD3pc1B1nAbUOB2uldjI7KPO9l2GkRa-- From nobody Sat May 11 08:05:56 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6B01200A3 for ; Sat, 11 May 2019 08:05:52 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 IPjFHzERVhL9 for ; Sat, 11 May 2019 08:05:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32EE7120020 for ; Sat, 11 May 2019 08:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557587131; bh=ruw9izYylmmQ1cJJDbbsmHeSXbILmIZD11rbm1WSg+g=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=atmc9f38U1zNfY5xOIgl4/ra29lrL+OTV9H1Ow5yAWPn+fYu4+FNRXYHiY64DL23E lbCN2+x7HUDbNGAmTFRkhjV0M/bBsd/CEYrs/aRho0dIIg0BEA7S+OCYnnqTNeMgNO gp2ME0z/oltBrGsOBU1IaLW+HHb8p71Lkn5KpvD4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.150.128]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MO9z7-1h5uVO1xQf-00OUgY; Sat, 11 May 2019 17:05:31 +0200 To: Henrik Levkowetz , XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de> <0755ffb0-490f-6ade-7526-12c867f3cd79@levkowetz.com> From: Julian Reschke Message-ID: <21311d7e-49af-6fa3-20b9-00f5121f6c21@gmx.de> Date: Sat, 11 May 2019 17:05:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <0755ffb0-490f-6ade-7526-12c867f3cd79@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:lhkZ8VT4NyrqeRslzouQAiqiou+SZ08H1vhxH4V29pAYun9YKzf zf7ernFM9vkZhG9NEXaJFg16zCfkSmwUtjcswz7ymefme49rCH3knfpaS5fxeWvkUJ724tT 22UOLGdWw45f7cIW4cB4Cp3hJ97EqVC3BV/hSvEveSg2oUjLIYNRmNr5Afar8godkwiKg+3 VDJNem8NLveSAOS+qM+zA== X-UI-Out-Filterresults: notjunk:1;V03:K0:YYwXTSnmZrY=:25HSge90iNHqLfAO9FVgLJ kR7SmvaxVIv/Fw3EHV1L325gUZ59vZJ+/Ejsl3tY+tl+hShueJ3J9QlpT0cFBC6/MoGoUgrx7 CfJYzzOLlgfmyZHXquKWFobFtUXNUIeCJuiHXQk1VIy55vQAvKzQb+Uyh2W7csIBx2Vrpp35x twY3T2XHAJjZFGGEXsmu/hfOFag4ETgAfFcwzUj2TPR8wyth0VHED8cqlRWMEOfFDX1xyJz6t bbwCGuUQj3S8hXO/XtgxJcKNMNOYxj/oApz+wDceWFFt7R6x8xBP/tqZXMk7U/fWjkXFK8sxa b4KL2g7REaa6DVgqLC4HTiM1w8TkOoa4Iy3dRJb2s9s/4vD711kBuhZGgINA3vZoBDmzzJ9dS XH4HnXh1ws+/la69ROzb/kQIzHxi3fqDD5IpAdYcWCPtgfj1kOk08ewS5dV3Q7K2n0B/a7Ch+ iQYSDSecOE1Xn9miyTLjtpYo3n9xrBDK+G/GBI4C2KXexCmnfWNlGFekUn+Ah0jrOn7LnH4ZJ kmoiLLQb/rNAfbdKXP75qpq5xyQOaY15bDyoDjlDrZbqnEz3JncCvPRkarM08O+sbE5iesO92 mfXG86gtxyIB6uD0Hted5wsSQdXhPiesS4c8rmSqD6sj9+bNTToGGA+rc4AWj1egLJs1xhPSv 9kKTD5iN8+n1S+qqCi3mTXkC4I52u0P4F87ZMAMWGXHB1wl8/OfnsgTGevBxHn8g43Gv97hVc hiYDDhxc5ZW3kA1tu3MqindKJ92SLyXeBl/KpsfNeU58xP8MwliiqFpxljv/aEXn55obYEzQb KFi6ievU50+E1jZ+8wHEFVBNaOpINyMl3lddLa6gqISEggvi0TYHLT+RrsUTT0cm7XAomnVlI CAlCcbia7FLckuzU2DYiVg1ysToLrN5fbMUhmwYvd3HG49SHuKYPsuLABrowdvybJNSSvGeuH LVn60TDOkpA== Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2019 15:05:53 -0000 On 11.05.2019 14:40, Henrik Levkowetz wrote: > ... >> So the HTTP specification is a description, not a specification? > > Could you be slightly more specific? Which document are you talking > about? RFC 2616, for instance. > ... >> As far as I recall, quote-title was introduced while 7749 was in the >> works, and we consciously limited it to what was implemented when the >> work started. > > So it's a description of the status quo at a particular point in time? Yes. But just because something describes doesn't mean it's not a specification (in case that's your point). >> We did indeed look at quote-title, found that the name was inconsistent >> with the remainder of the vocabulary, and picked quoteTitle instead (in >> 7791). >> >> I still don't understand why you just don't fix it in your >> implementation according to the spec. > > You're asking for something that would break existing xml? a) I did research and found just a few XML files (in AUTH48 history) that used it. b) Feel free to accept the other form as well (and maybe emit a warning). Then there'll be no breakage. > The current xml2rfc understands both, and the v2v3 converter converts > quote-title to quoteTitle; if you're asking for more, you're asking for > ... That's fine. >>> ... >> Good catch. So the TCL code did something weird here (also not what it >> said it does in >> ) >> >>> I'll adjust the v2v3 converter to produce in the v3 output wh= en it >>> comes across both "src" content and inline content in the v2 input. >> >> That's nice but I don't think it's sufficient. > > Ahh, but I think it is. Difference of opinion, here. > >> This simply is and had been valid input, and there is no reason not to >> support it in v3. Well, except to justify the introduction of = :-) > > So there's a lot of the vocabulary that is marked deprecated. I'll just > permit all of that in pure v3 too, then? says: "Deprecated elements and attributes are legacy vocabulary from v2 that are supported for input to v3 tools. They are likely to be removed from those tools in the future." So I'd say yes, they should be accepted. > I understand that you don't like . You've said so repeatedly, a= nd > it looks as if you can't let it go. I'm fine with you having that opini= on. > ... Well, if you don't want to back it out, at least take my implementation feedback seriously. Best regards, Julian From nobody Sun May 12 13:19:45 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFD212011F for ; Sun, 12 May 2019 13:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5Hr8m4G9ny2 for ; Sun, 12 May 2019 13:19:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9992C120026 for ; Sun, 12 May 2019 13:19:42 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:56540 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hPuwb-0006f1-D6 for xml2rfc-dev@ietf.org; Sun, 12 May 2019 13:19:41 -0700 From: Henrik Levkowetz To: XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de> Message-ID: Date: Sun, 12 May 2019 22:19:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WUeJeHTdJtfEhBSfEQekfqxT9UlXjpjcf" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2019 20:19:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WUeJeHTdJtfEhBSfEQekfqxT9UlXjpjcf Content-Type: multipart/mixed; boundary="w95Eb5SQKFmD5gc3lDpRSPgPJIcjp6kKv"; protected-headers="v1" From: Henrik Levkowetz To: XML Developer List Message-ID: Subject: Re: [xml2rfc-dev] feedback References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de> In-Reply-To: --w95Eb5SQKFmD5gc3lDpRSPgPJIcjp6kKv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To the list: After the latest discussion, and in particular this: On 2019-05-11 14:26, Julian Reschke wrote: > /me shakes head I'm going to black-hole postings and direct communications from Julian Re= schke. It's a pity, because I'll also be missing his factual observations of bug= s in the tools, but the emotional cost to me of discussions with Julian is now too high. Henrik --w95Eb5SQKFmD5gc3lDpRSPgPJIcjp6kKv-- --WUeJeHTdJtfEhBSfEQekfqxT9UlXjpjcf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlzYf9IACgkQTptXS4+7 Fxo4XBAA04sK6swX+5VGL/iIMKP292CyhDx8RWF2K4uQy9OehVfOYDVj0L7JLaHW +5UhnGMwa0OAoiOrsxlyJOjxE9x6rJgvizORhgnIunb5lNM1MwuDZ3JQfvZqZ8pg 3P5HDg/CbAlXj5XFuG4G5touDkbaRVcbYP0hMPusr7MdJ3xpTLNqmtfphnnMg/Hh 3QnyBH3wiWUK4LcrmJ8yNmvMExDbLo/5/F2PA/8UceTr3Yupl2vik+S4yb0ZfgTv 5gyWGQ2+ox5L28wT5m2/0EqmpEEioC+Aj2Cv4qavizNHCOnDju/1BocrttNhpDN4 E2AMJVuAA16l59O3kuZeRs0ifJ1MnZe0YQG91qWgJwTHXK2T+UynlEf6b/X+lnB3 rIOOiJkp9l5OBsb9rMmqlhh6vi3JuO6062xMMZn0IK87RWJI4qAxL+nFX7h0I2q/ pHa/TJXVfSys8LlQfB1Yz95Cve1X0cdny1rGa3nWXWPqLqUxq4bYWbotDDT+W5P5 iR9Pq+L56H+av5KmBfbINTpHGhjPHrjoMN8wF9mmuGdp7rL3V+yi1S8IWAcQwXST KYWDgUPkz7jZ71lZ6ycdwIAAruzc5GfYOOtnLn306/CoezzGOvttV7ycV+DPJVir AMEGAF+0tmFptznoBAzGQlgfW2gaqtVno488mII94/qP/8elGNM= =5ZXF -----END PGP SIGNATURE----- --WUeJeHTdJtfEhBSfEQekfqxT9UlXjpjcf-- From nobody Sun May 12 21:47:23 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FE21200FA for ; Sun, 12 May 2019 21:47:21 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 5Pc4fVlsbod7 for ; Sun, 12 May 2019 21:47:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85151200EA for ; Sun, 12 May 2019 21:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557722823; bh=ujiyHq3SRgcokRT/cWNAiL4tUPBl0VPEI3muns2vDwU=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=dnT7BhQoaX6fM9KB/T8jjMWXz48ztsQDR2HkhK4B7vWsLph4+atj+ozxnfK5ayr3P YVp6N5/ayQIoPNam6z0ARnmrjpzAlmQp6AnhkCNooM2rVtx7O9wInt662oJbLWmqol gtglAsvax93MQOrBDNKRo+fCJM6fJ5K2CuGM3Sk0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.149.96]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MXXyJ-1hCSCm1dnD-00YyxF; Mon, 13 May 2019 06:47:03 +0200 To: Henrik Levkowetz , XML Developer List References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de> From: Julian Reschke Message-ID: Date: Mon, 13 May 2019 06:47:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:8kDntjQQ3o5KP+lJenIeNZQljTujQDZm+/PJj+PO9GJ0j9ecmEC A0s7ULV4NyceEp85WdyvCOAmDrFuUHm+jbyEQK1HOwHsU0ircFMG0rY0wtNUDYpHyaCtZYC Z8idJYuFz4T98j3cyOm0EtFk+j2v9HlASliwxnlo6SIlsRLh/wsJW385s0eB27d5wcZZ5PL LEsWxqMdv8vyv83MFUTTg== X-UI-Out-Filterresults: notjunk:1;V03:K0:zVUYgJrxbjA=:XaFXs58RSdaFMN89cmxVpB YFIgByecP53jnNlrCj0GkgK+eqMCCQ+Tf7J8ORJrUYChOHaroYGCg172sniWOj72zEj3BujsB 4mjnaPf6vRXIwvVDl2OOg4lWBVTcpB4Hb1uZAuiCmCH4107x9b6XQVzzXMIZwlrL5oIwz1ZM1 Ao2NZLYHh6IHi1Uhszv2aUrIqGyDdYnQvqqvvd+ouoQUnDayNu4Q7iui++wRdUf6slDJrIszd oZlKI/NKbChzlJKbAZ2GjiVpN2Cpn+oHdpI1dK8HONPXexN9TZsfVo8XM6klthZWSMrGujAUl 6oQX2KwkfgiBhQ3h4WhYEqTSt9pdWFo3WPdHgwkPOm2D1KGRxjlATXJHo4E0MvftVAo9Z9gSD BbC180ruUOd20TPqL8DumqSXIzfnO8czi26Nk9MVecTuWxl88q8YvI9A2vW119R3e/bMcJDdn AdNrKP4ZNHxFmDA2LKhaVS8X3rle3Z9rLCl+agVV7050X3iqZT5GJ0GsYF0+4mRaPkodaz8MB NVu9peDcMQ0uzJoq6vdsMgDbDznmjkBWveyEnOt1z6P2qByYTcm+AB57YfdbE0u81rN29I2AV sCT65EA+XUVQCeK+QDNSNCYQFdpe/6qUziuk91e0eoSG4xAYSJAVGJj4R1naGbiLfg+TJOCRl KudlBIuGoehRw5bunemP6xjq1Ny4lFBBmgc/3gYcsLNvnGQZiRYY0aXMwH63bVfcrxrAEOapK /TxmcxSW5BUr/027ehQi5LVH4t1hxzHDnPhH/WS7H+auzXHcEIIu+CbbcMay0g7Byg/o1r+av 5Ib/ioUlGGl/BJ4P47+ERJF8urSiDSf2h368Tsx4svjJuDs2Mao5qMPz7grP7hxjzuPKDqZWc /wbRAKv8rOP6tJx/QJwIoP6Z/Pl/sGlA9OnOP1Z2TPJ3LaECb3mPpCNQ/6Z6BFLlSDCEYt43R Rbh7/dxj63Q== Archived-At: Subject: Re: [xml2rfc-dev] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2019 04:47:21 -0000 On 12.05.2019 22:19, Henrik Levkowetz wrote: > To the list: > > After the latest discussion, and in particular this: > > On 2019-05-11 14:26, Julian Reschke wrote: >> /me shakes head I recommend reading this in context. > I'm going to black-hole postings and direct communications from Julian R= eschke. > > It's a pity, because I'll also be missing his factual observations of bu= gs > in the tools, but the emotional cost to me of discussions with Julian is > now too high. > ... It's indeed a pity, because with that the process of finalizing the v3 vocabulary would be entirely broken. Best regards, Julian From nobody Mon May 13 00:28:20 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277A112002E for ; Mon, 13 May 2019 00:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgzMQFKJdcFL for ; Mon, 13 May 2019 00:28:18 -0700 (PDT) Received: from mail.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5AC0120026 for ; Mon, 13 May 2019 00:28:17 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 13 May 2019 00:28:15 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Mon, 13 May 2019 00:28:15 -0700 From: Paul Hoffman To: XML Developer List Thread-Topic: [Ext] [xml2rfc-dev] feedback Thread-Index: AQHVCV1tybta7OtqJUKpC2loxminoA== Date: Mon, 13 May 2019 07:28:15 +0000 Message-ID: References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <13BB44FFBBF55647A7E0E248DADF16FF@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [xml2rfc-dev] [Ext] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2019 07:28:19 -0000 On May 13, 2019, at 11:47 AM, Julian Reschke wrote: >=20 > On 12.05.2019 22:19, Henrik Levkowetz wrote: >=20 >> I'm going to black-hole postings and direct communications from Julian R= eschke. >>=20 >> It's a pity, because I'll also be missing his factual observations of bu= gs >> in the tools, but the emotional cost to me of discussions with Julian is >> now too high. >> ... >=20 > It's indeed a pity, because with that the process of finalizing the v3 > vocabulary would be entirely broken. I agree with Julian. During the process of developing the v3 vocabulary, we= did not black-hole postings from anyone. --Paul Hoffman= From nobody Mon May 13 07:49:03 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1199712009C for ; Mon, 13 May 2019 07:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEN86OVtNL2W for ; Mon, 13 May 2019 07:49:00 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8A3120094 for ; Mon, 13 May 2019 07:49:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id A43CB1C163C for ; Mon, 13 May 2019 07:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXypYeM_VTWj for ; Mon, 13 May 2019 07:48:47 -0700 (PDT) Received: from [10.198.42.38] (c-71-231-216-10.hsd1.wa.comcast.net [71.231.216.10]) by c8a.amsl.com (Postfix) with ESMTPSA id 67EA11C1380 for ; Mon, 13 May 2019 07:48:47 -0700 (PDT) Date: Mon, 13 May 2019 07:48:53 -0700 From: Heather Flanagan To: XML Developer List Message-ID: <405e689a-2bce-4d12-88af-2ddbe61103c9@Spark> In-Reply-To: References: <19522381-3529-e66e-adb4-3a1c7d5ee9ea@gmx.de> <4fe5ca5e-4fbf-6ca8-36c7-1d1b93dfc07a@levkowetz.com> <10473b16-04b7-7c48-cd29-fbd5d3e15ee8@gmx.de> <2f56f446-68b3-4755-54c5-213481a7068e@gmx.de> <3c2062f4-f529-199f-2b70-70929c10fa84@gmx.de> X-Readdle-Message-ID: 405e689a-2bce-4d12-88af-2ddbe61103c9@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5cd983da_78df6a55_fd" Archived-At: Subject: Re: [xml2rfc-dev] [Ext] feedback X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2019 14:49:02 -0000 --5cd983da_78df6a55_fd Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On May 13, 2019, 12:28 AM -0700, Paul Hoffman ,= wrote: > On May 13, 2019, at 11:47 AM, Julian Reschke = wrote: > > > > On 12.05.2019 22:19, Henrik Levkowetz wrote: > > > > > I'm going to black-hole postings and direct communications from Jul= ian Reschke. > > > > > > It's a pity, because I'll also be missing his factual observations = of bugs > > > in the tools, but the emotional cost to me of discussions with Juli= an is > > > now too high. > > > ... > > > > It's indeed a pity, because with that the process of finalizing the v= 3 > > vocabulary would be entirely broken. > > I agree with Julian. During the process of developing the v3 vocabulary= , we did not black-hole postings from anyone. > I don=E2=80=99t like the idea of black holing, either, but when two parti= es start arguing past each other to the extent I=E2=80=99ve been observin= g, a cooling off period is necessary. I=E2=80=99m still watching for inpu= t for all parties, and expect a very engaging -bis process to start when = the final implementation diff draft (draft-levkowetz-xml2rfc-v3-implement= ation-notes) is posted. -Heather --5cd983da_78df6a55_fd Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline


On May 13, 2019= , 12:28 AM -0700, Paul Hoffman <paul.hoffman=40icann.org>, wrote:
On= May 13, 2019, at 11:47 AM, Julian Reschke <julian.reschke=40gmx.de>= ; wrote:
On 12.05.2019 22:19, Henrik Levkowetz wrote:

I'= m going to black-hole postings and direct communications from Julian Resc= hke.

It's a pity, because I'll also be missing his factual observations of bug= s
in the tools, but the emotional cost to me of discussions with Julian is<= br /> now too high.
...

It's indeed a pity, because with that the process of finalizing the v3 vocabulary would be entirely broken.

I agree with Julian. During the process of developing the v3 vocabulary, = we did not black-hole postings from anyone.


I don=E2=80=99t like the idea of black holing, eith= er, but when two parties start arguing past each other to the extent I=E2= =80=99ve been observing, a cooling off period is necessary. I=E2=80=99m s= till watching for input for all parties, and expect a very engaging -bis = process to start when the final implementation diff draft (draft-levkowet= z-xml2rfc-v3-implementation-notes) is posted.

-Heather
--5cd983da_78df6a55_fd-- From nobody Mon May 13 23:54:41 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042FB120157 for ; Mon, 13 May 2019 23:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.20150623.gappssmtp.com 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 Kbv3vbVdBmfK for ; Mon, 13 May 2019 23:54:37 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A162120187 for ; Mon, 13 May 2019 23:54:37 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id d9so9439928wrx.0 for ; Mon, 13 May 2019 23:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition; bh=1267KEtuTG6EjHqp9xw+pVF8ZMEHRO6Uyae4zDaBxos=; b=sWhBa1eUrSAnFlVGN+eFrrijbjoNuQghMXTR/NiVLDXgiOZpbsRQ4by8G7g+hjtcjF mfzcH1RUaYPfnichSN10/d1wL/6dSvbctey09u0zCkAlTCeD9fuXEfkdt+Y4mcC9i9lO qh9yLo6dPVTTfZ/tNjXCftIdNXo+VEFCbeodqWVNKfAQJ1ev/W2oFwkh2WZl/8fhQp25 7yRq3k2SstQ6Zdj/toy2ac1rAALz2zNP7XuwtNCWnf3bzmsbcsJL7YVL7IVu1VPOBdY9 fBjQUEL+2/bMY4P5Q1FUNopy7dk9J4jEUC7OQb1XmxoCFGEAwE2KHeYd04HCVKrR4iSH vzVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=1267KEtuTG6EjHqp9xw+pVF8ZMEHRO6Uyae4zDaBxos=; b=RKEnKoZf8iD0zP7nd3R62QIZfS2/z6uEub6Fv328wSY5CPByDbsDfiYDpwPJyBkOdD gl/pxHmEtboOJZZvmMNcA68M1NS5aKrESrnIK/F8xpxEOv7ZhffkFg0DRvx/0zSgIzeK y+lfElZBleLAQMh1+joN3RpGK/61h947iG9+p1yG4haM7aV1cj3xJQ0ssQ3KM4Bqt0w2 jAo5FmjwrNEqpAoAI46g4NonJ1F8t5AHDQ0CR6f3yvdsbarSp6L0UGRwsk4lFvv+pb0V m3oyjsezuL4twvb30oMrS8DUcaysJWtShIFT8vhAeURqIyqCBOSZhsFIj5YAsn9AASPu vmag== X-Gm-Message-State: APjAAAWrIb0uvDLGAKcuQck+nGDv/Dava3/iJcHFwSh5qam7IEQTUqi0 tZznl8ZOZwYiCtRJxWmSeNX1mVsbckw= X-Google-Smtp-Source: APXvYqwRhu1GkfQOU8a0EtQ4aAYBzOTDJdXOy4TA+PZJKcbzXPy0/bq/+InGoTbRpR6JgK/OzWupZA== X-Received: by 2002:adf:eb84:: with SMTP id t4mr2135147wrn.43.1557816875471; Mon, 13 May 2019 23:54:35 -0700 (PDT) Received: from miek.nl (router.mikrotime.com. [81.187.237.61]) by smtp.gmail.com with ESMTPSA id a6sm13346069wrp.49.2019.05.13.23.54.33 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 13 May 2019 23:54:34 -0700 (PDT) Date: Tue, 14 May 2019 07:54:32 +0100 From: Miek Gieben To: IETF xml2rfc-dev Message-ID: <20190514065432.djwufenbgwrvbktt@miek.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Archived-At: Subject: [xml2rfc-dev] empty workgroup leads to crash X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 06:54:40 -0000 Hi all, If the workgroup is empty xml2rfc 2.22.3 crashes with the following stack trace: xml2rfc --text --v3 draft-gieben-mmark-00.xml && rm draft-gieben-mmark-00.xml Parsing file draft-gieben-mmark-00.xml Traceback (most recent call last): File "/usr/bin/xml2rfc", line 11, in load_entry_point('xml2rfc==2.22.3', 'console_scripts', 'xml2rfc')() File "/usr/lib/python2.7/dist-packages/xml2rfc/run.py", line 549, in main writer.write(filename) File "/usr/lib/python2.7/dist-packages/xml2rfc/writers/text.py", line 228, in write lines = self.render(self.root, width=72, joiners=joiners) File "/usr/lib/python2.7/dist-packages/xml2rfc/writers/text.py", line 271, in render res = func(e, width, **kwargs) File "/usr/lib/python2.7/dist-packages/xml2rfc/writers/text.py", line 2834, in render_rfc lines = self.ljoin(lines, c, width, **kwargs) File "/usr/lib/python2.7/dist-packages/xml2rfc/writers/text.py", line 446, in ljoin res = mklines(self.render(e, width, **kwargs), e) File "/usr/lib/python2.7/dist-packages/xml2rfc/writers/text.py", line 271, in render res = func(e, width, **kwargs) File "/usr/lib/python2.7/dist-packages/xml2rfc/writers/text.py", line 1604, in render_front text = '\n\n\n\n' + self.render_first_page_top(e, width, **kwargs) + '\n' File "/usr/lib/python2.7/dist-packages/xml2rfc/writers/text.py", line 1796, in render_first_page_top left = get_left(e) File "/usr/lib/python2.7/dist-packages/xml2rfc/writers/text.py", line 1723, in get_left left.append(group.text.strip()) AttributeError: 'NoneType' object has no attribute 'strip' Makefile:8: recipe for target 'draft-gieben-mmark-00.txt' failed make: *** [draft-gieben-mmark-00.txt] Error 1 /Miek -- Miek Gieben From nobody Tue May 14 03:37:37 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AC812006B for ; Tue, 14 May 2019 03:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVIWsi-E3a7h for ; Tue, 14 May 2019 03:37:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86B512003E for ; Tue, 14 May 2019 03:37:33 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:49226 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1hQUo5-0003dF-8O; Tue, 14 May 2019 03:37:32 -0700 To: Miek Gieben , IETF xml2rfc-dev References: <20190514065432.djwufenbgwrvbktt@miek.nl> From: Henrik Levkowetz Message-ID: <324ad08e-41a9-6c78-0a5d-006816822649@levkowetz.com> Date: Tue, 14 May 2019 12:36:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20190514065432.djwufenbgwrvbktt@miek.nl> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XHTvARwPQScS1cJg7xMpava3toWsub7MP" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, miek@miek.nl 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 zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc-dev] empty workgroup leads to crash X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 10:37:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XHTvARwPQScS1cJg7xMpava3toWsub7MP Content-Type: multipart/mixed; boundary="pkAho1e9Mp4ciBSTNoHnNHomSbnJAkLnV"; protected-headers="v1" From: Henrik Levkowetz To: Miek Gieben , IETF xml2rfc-dev Message-ID: <324ad08e-41a9-6c78-0a5d-006816822649@levkowetz.com> Subject: Re: [xml2rfc-dev] empty workgroup leads to crash References: <20190514065432.djwufenbgwrvbktt@miek.nl> In-Reply-To: <20190514065432.djwufenbgwrvbktt@miek.nl> --pkAho1e9Mp4ciBSTNoHnNHomSbnJAkLnV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Miek, Thanks for this. Would it be possible for you to enter a ticket at https://trac.tools.ietf.org/tools/xml2rfc/trac/newticket ? Best regards, Henrik On 2019-05-14 08:54, Miek Gieben wrote: > Hi all, >=20 > If the workgroup is empty xml2rfc 2.22.3 crashes with the following sta= ck trace: >=20 > xml2rfc --text --v3 draft-gieben-mmark-00.xml && rm draft-gieben-mm= ark-00.xml > Parsing file draft-gieben-mmark-00.xml > Traceback (most recent call last): > File "/usr/bin/xml2rfc", line 11, in > load_entry_point('xml2rfc=3D=3D2.22.3', 'console_scripts', 'xml= 2rfc')() > File "/usr/lib/python2.7/dist-packages/xml2rfc/run.py", line 549,= in main > writer.write(filename) > File "/usr/lib/python2.7/dist-packages/xml2rfc/writers/text.py", = line 228, in write > lines =3D self.render(self.root, width=3D72, joiners=3Djoiners)= > File "/usr/lib/python2.7/dist-packages/xml2rfc/writers/text.py", = line 271, in render > res =3D func(e, width, **kwargs) > File "/usr/lib/python2.7/dist-packages/xml2rfc/writers/text.py", = line 2834, in render_rfc > lines =3D self.ljoin(lines, c, width, **kwargs) > File "/usr/lib/python2.7/dist-packages/xml2rfc/writers/text.py", = line 446, in ljoin > res =3D mklines(self.render(e, width, **kwargs), e) > File "/usr/lib/python2.7/dist-packages/xml2rfc/writers/text.py", = line 271, in render > res =3D func(e, width, **kwargs) > File "/usr/lib/python2.7/dist-packages/xml2rfc/writers/text.py", = line 1604, in render_front > text =3D '\n\n\n\n' + self.render_first_page_top(e, width, **kw= args) + '\n' > File "/usr/lib/python2.7/dist-packages/xml2rfc/writers/text.py", = line 1796, in render_first_page_top > left =3D get_left(e) > File "/usr/lib/python2.7/dist-packages/xml2rfc/writers/text.py", = line 1723, in get_left > left.append(group.text.strip()) > AttributeError: 'NoneType' object has no attribute 'strip' > Makefile:8: recipe for target 'draft-gieben-mmark-00.txt' failed > make: *** [draft-gieben-mmark-00.txt] Error 1 >=20 > /Miek >=20 > -- > Miek Gieben >=20 > _______________________________________________ > xml2rfc-dev mailing list > xml2rfc-dev@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc-dev >=20 --pkAho1e9Mp4ciBSTNoHnNHomSbnJAkLnV-- --XHTvARwPQScS1cJg7xMpava3toWsub7MP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlzamkoACgkQTptXS4+7 Fxp6WA//cuH2DrF/curlb8riXJTQLOaEy2KEMcBSCnj52KC+jLlPFUUvhRKA+fDI Colcgqy6k76N8y0En07BZ8T/xvSJEWsfw+ZXhYv0j4g4FXh9mHitlza0ZvSeMfAj cotqyasuh35BAF8j2lS32c7stOtxjEmhRVHonr/3xu1a2hV5dm8k8+i5GKZNroIM X3R7GRVGZv6E7HbjZZHZW4UK3lPSllKFhmPLiKMVzwQpV3xlY9C7iDNwy47YQOll mkkQBpGlv3fMbNsnsejdVsK7R3XHhSRftRFeJyds/+UnJQdHnAP5qp6DVeCYAiwi dZ/HNhQ59i5KC8IXPSsTbWrIKwOkc+t+4mXXd2dsDLya0yEWH9XA9l64RNEOypvY +4a8P/q8bK5lwhmXZD56csBzFj4GN2u84V1YvB1BjZBRbURB08Cnl++LXdjDJU4Q AOP9jdWAPjNAbsHwqAUAvoMVJ4uEmCiXr8kW2ppwsnNE6gDARMtUqUbXrem5gWBm 8IxeYrfNDPE7wZ5RtCdRE5YpM/NNMmaJSUIiaudbfvqF2jIUjM2xQBZzKCNYVNJq saNll/aJDbkCvfkdGnAEBzfLlRuQmR3LrAQi76/Lb7rX2ZU3bBOU29IKzKnRTJ1X 4009Vm1yPMR1Kk0klIlFNzfWN01wa0TstR9ldde3OjdXMXMKwLY= =22cw -----END PGP SIGNATURE----- --XHTvARwPQScS1cJg7xMpava3toWsub7MP-- From nobody Tue May 14 10:56:47 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96EB0120168 for ; Tue, 14 May 2019 10:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 qwzK0fzPErYV for ; Tue, 14 May 2019 10:56:43 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4691F12015C for ; Tue, 14 May 2019 10:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557856593; bh=FtsYWr5cv1HWCIrwjOt1Y6m9cCWVlNkGMX1SlHuQyjY=; h=X-UI-Sender-Class:To:From:Subject:Date; b=eyuJZgP0N7u3iy14mCA592kyn3gJHrXyC8G2C7cZLlPVJEhB9ewg0TTVZWJB8reZm 4KQcVYCIPVmzep7eom/hrDrIk0DCfK23n1UWd9ikwU9Z8+n2DTGCseyf4WXSNk98nD vmt2MD3cQ10vgUfnP6U5+kpdJpP7zTAs4izQhG0Q= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.148.117]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MRTRN-1h5WPE0HGn-00NOHs for ; Tue, 14 May 2019 19:56:33 +0200 To: XML Developer List From: Julian Reschke Message-ID: <886bb00b-e075-7b29-7eb9-7d57a5769c78@gmx.de> Date: Tue, 14 May 2019 19:56:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:uYUx0GNxURIFtfemSSrGkIl2HKxgUoFL8FOv3HUVrYMQZatgk9o 0qrWRQY0vR4we1tW1vtvXscdu7DVWGfeeapXlcF/82d0fdVKZMRLrOErUGjoU89m6uV7CUY BzU7nsIycQz70VKf1PV4+2XLOKYbFKRw0UJ3WrbGfrTvwzMavpYJHpj/x2se850Gp9MAW/r l0mNxMiWtOYbv/yRVm+cA== X-UI-Out-Filterresults: notjunk:1;V03:K0:sqD3meh57hE=:ifm0UFtH8eSJCrPmtc4QeC mnpGblx/AIDJ3OeVH3+EAPmFISZlXpGhtmhS2KNEJdSJ1Tcc4/C/iM4MlTIFDYs6CzcytT/ic WWap1AiKLa8/6mweSDiK46cEMsPFoDsgNWlxujr3kuAQWeXnHXvxTp/dBCGiDOZ5QP3ylfRZ4 Xa5BuUht+02+0cfIppsA9n9Wlefl/Bx72vWgTd+58AJgt/Tez2ZdZI3g+a9I9qp1vh8FG2yio vDuWvtGBmC9+h1hmNgF+LjBDyTc1mzokZkBrRWBh1vZgy/A6AJVU7pEvWUCrUjUGza6pQnR5K m8ub+vMh8nd4EPUPfYoy1awUJ7SsrA/Qbw8bUnZb1wCgmVuFun+qbO2ZvW2C7X97sIGt6Yo6b fCbDw4UvE4fauMyu4oa/HwAgZe5Konv9GI8CF+FqIYe/9f8swp703A2RFrNswbDlKuVPNvZY6 7+44C8jw4vxDFw/ogZGIEYMQGephUOHBhnMCQVUOSwbD4kOHrxy/BtMSkPzkHBnRWjJJOdD8p T9rURsaI+VpRRwiw9f4BxDs73XhjxPtBOITlwXcJgSMumAmfqd1lY4prKm2mcu8UWknQLEQ+/ KPvlQMRN4l1n2NZaGEHN5YB+STVSsyQFIxgaZd9mDwr0Gxrc52Y7xj0DOZCK/1fe42f6QLQRG opguql6K9NxoJ7CDnMVMtLGaVJBMP0zLoyrIE7xVXZhR9uLORauVhlIUxp0tB+FBRpIXEgYur M8kUh3UZyplAW9Ffwt5ycCF/TKSnjR6h/dNA7fKnwjAIMtvHPAREnMcLp4wXYH4G9h9Y8w/M7 1i14LOOtji8+TpLtbCoKwPTWVu30EbU3+6M/36qludtvt7A47GwDZF4sQYsEDFYIGuTFbke74 QAh4RFb031txzez8o3Kfzo1XNHfHfBYvzwzPAFGtKFGFIjvIZb1zXyOFnP8gHjtf/h3RrcNwp Jidpz9IA+0Q== Archived-At: Subject: [xml2rfc-dev] feedback on feedback of X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 17:56:46 -0000 : > 3.1.15. In Section 2.41, > > If is to be used to represent for instance an STD > entries that consist of multiple RFCs, the STD itself will have an > URL. It would be natural to represent that with a "target" > attribute, as for . > > Proposal: Add a "target" attribute for the one for > Implementation: Implemented in xml2rfc v 2.18.0 I agree that this is a good extension, but I note that at least for IETF BCP/STDs etc, it can be automatically generated and the target attribute would not be needed. > This issue is tracked as github issue #48 [11] That is , which is about something else... Best regards, Julian From nobody Tue May 14 11:00:21 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C70120137 for ; Tue, 14 May 2019 11:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 Z0LD69MVFC94 for ; Tue, 14 May 2019 11:00:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36381200B1 for ; Tue, 14 May 2019 11:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557856816; bh=TUb5RZG1/7gIARFEFk5m2IbZ9ceoLS/cr/+5/LTgHP0=; h=X-UI-Sender-Class:Subject:From:To:References:Date:In-Reply-To; b=Mx2qh3QdtOSoA4wkB6je+PY5+OB1cP5gNZ0wZU4B6358mj/ek1gtbJsebkRQKCmMx cUv7VAhROjP6IHq3fD+xffj8aLdzlz0pockvyxIBdZL04h8UyAugYfnWDYRfEpUOY+ 04rRBFLljvH4Q8j84Yklge4JJJPWjb9m2h/Vr/QU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.148.117]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MZTmY-1hE54Q05Yc-00WV5q for ; Tue, 14 May 2019 20:00:16 +0200 From: Julian Reschke To: XML Developer List References: <886bb00b-e075-7b29-7eb9-7d57a5769c78@gmx.de> Message-ID: <9724dd16-12b3-5cbd-23ed-96854de46079@gmx.de> Date: Tue, 14 May 2019 20:00:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <886bb00b-e075-7b29-7eb9-7d57a5769c78@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:PafmwhQsy4Rs0IZEeoV5UjlNefAx5lMjy2deZvYDf/8iPtgwm9B gjGT3gTBYlZJDSj6VHak76+jMD6qLhb97Mpus64c1uhYZN1RAUXQ9JTUXfRy3KEEE2lPKHZ HXQhPDzjUYX4PvJs+zoW2qqY9yMpwsYldW4oavCntdK+JGzbBeVPHNjL6+g8+8U2IGRILer 6NxwZtbIYQooRyMrElJPA== X-UI-Out-Filterresults: notjunk:1;V03:K0:f7wduWx0gWQ=:1BHZyk7FkhY76FLnGijxYB 3XRVao9VEEge1txClPRgwkqLH8omIjIr4Fh8IwuIJfp1CUJwNZOCf1cza/8pIQe5E3Vz/ZPRU 7dYQQfxxPBlXhm8aYtqZrMzrOgMtjeXyvwp7A2tHuT8jcXOarqMuM/AftOqg30u+/f/pdBLhO hn8COE4iTNXKDkPDPEwf5yPbBJ377m+rdTfdSbmb9VgYMLAPB/j9eKMlAPFgsFDrFULFuNZB3 pMuG1jDnTQSHp4jqEAl97+LDTvVTSr5fuwfj0AvO9ydn9hkTkr/8TK2vUWP3VqGLJTr+JWLlo gt5DMpio3KYc907tm12aJBogFvtWxa7KlfOQ0HXaWr4R7X5hxYlKIzi0AMPM3o9br5cP/L139 8Schs5QTcCHtm+oDy6s9TyDoeOi8fKR2m4CiclFWYpwlZ4t3khlO2NoGuz0rXPjpu73Daipd5 oY1Bip6PuuWIci3LwbedygLiGy/o+4nhc5PkAFSsTyA+d5RqlfAbccfBzSo4BNS7d7eh+zFHW IPbPp+XQinBqwsNZfDjyFHjUJM0i0pH5ZpZGWf1r4t2Au7USe4wkRJvwjyf62o2bODB+dZh/n KxcWRqQjmY4ajUKsQps586IiX8qGdnSmanFjUTaUu/pmM41bRK20Ro7seCXTmt8T9csVqx0P/ EskaTxAScSqEs/VoBXdQNazA7uMrBYTMgBCN/Hn2uW5UwA+IvqJg6g60r3nVsstESLjgkE50g MUg4wgKAwDyDhh713YqWzmdELz7oiYBTUhXPMfPdQ2y9wLHiFRedWZBZLEH4JErPUIZ0UEaI8 B52d0AF0B5vvHNBGLvC6JK2gh54kQK9SCy3vv5j3Uvyhpa+mVbV673rons+VH64r6PIBrzCDD 7tHUcicQtGTDm/aYP5SU3rd1KIaZn6c8+NKwWri4H8ZwKHqS2rgLQ7KH06NiFikfUaWXrJl4j 2gEuSCgD0Zg== Archived-At: Subject: Re: [xml2rfc-dev] feedback on feedback of X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 18:00:20 -0000 On 14.05.2019 19:56, Julian Reschke wrote: > : > > >> 3.1.15.=C2=A0 In Section 2.41, >> >> =C2=A0=C2=A0 If is to be used to represent for instanc= e an STD >> =C2=A0=C2=A0 entries that consist of multiple RFCs, the STD itself will= have an >> =C2=A0=C2=A0 URL.=C2=A0 It would be natural to represent that with a "t= arget" >> =C2=A0=C2=A0 attribute, as for . >> >> =C2=A0=C2=A0 Proposal:=C2=A0 Add a "target" attribute for > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the one for > >> =C2=A0=C2=A0 Implementation:=C2=A0 Implemented in xml2rfc v 2.18.0 > > I agree that this is a good extension, but I note that at least for IETF > BCP/STDs etc, ... ...and it turns out I implemented that in February () and forgot about it right away... Best regards, Julian From nobody Wed May 15 00:20:33 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B771202B7; Wed, 15 May 2019 00:20:23 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 8TPZ6oDcRSui; Wed, 15 May 2019 00:20:20 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00742120255; Wed, 15 May 2019 00:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1557904786; bh=BaSo6ej4fT0lHcnCHmeOrsKmA/C20/zBBXzkgomWMoY=; h=X-UI-Sender-Class:Subject:From:To:Cc:References:Date:In-Reply-To; b=IunDx012dXyL6NrpqgCyEZM/Rco1p1pHDsD9gu3/mPleyip+Fqt6gck2wZrffSzQk XVO3WTa5hYe+uLOEMOVzElkUsJcPMK/9mZzBVD6Y76lQjWCzGHLwsYr903clS+Plix gjf1BL2wdIgb6CUgNWcC9DNc4DZAUf/CVc2OCGzM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.148.39]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mg6Zq-1glOZg1krO-00hgCG; Wed, 15 May 2019 09:19:46 +0200 From: Julian Reschke To: Henrik Levkowetz , Miek Gieben Cc: xml2rfc@ietf.org, xml2rfc-dev@ietf.org References: <20181029204446.xwjkdfdpj7sbhvsr@miek.nl> <0455bd48-3392-bb4c-f510-c57489792606@levkowetz.com> <20181029214325.5i3rrv55dpamvbsa@miek.nl> <1d03c466-bd4a-934e-18f0-f9ac5bc2225e@gmx.de> Message-ID: Date: Wed, 15 May 2019 09:19:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <1d03c466-bd4a-934e-18f0-f9ac5bc2225e@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:P10U3lEY3+z+ish6k7oEfZE5CkfPdRLXLDaDeuLF8Iw9bfVfk1d +tgFNgAlTvFTNlbd2jK8ATbZLfSTr6HFaLuCf9ZC7gStE0GLKhCEyCBG21SmVJqZoqozMe6 6s/sLkSD0/VxwDVGe3ACK+nGsYwwutgp2RVjBzx0I77l0/Mdvxoyo96SrShXZD8yRaVDplc +fB6Av2Lp5sfCr2rrJ3Zg== X-UI-Out-Filterresults: notjunk:1;V03:K0:J4vvdVVcWHs=:gqIBWkefafODAHCduW4v9+ UlqSuExBtSqt45eUtH1WcRpnTkZi77hjUDjG4SPLBmnTUJHlwwzLg6jm6siCbH90G50vtA96R KrR/S3HtmdDo76Kr3C2/hlCkhCFgeN3qzEW9QKIf3/9USLQejNWr617Z3Jd6wqVSBMsy+xwQu Ri8c4NGYYIkWzaMIMJ7PApEWl8WDM7Kf20y5jsJOAmb0B/RXjLa99tA1GiVj/v6ggaKQmW5EY DX/CK6DN/8P6qtYG/g5AtngY69Dr/bf+BlA9Sh+kMgxlUjmbep5B+oCHof59OHecHrD+dzRXt ZYzET1g7K8vkZC+sYVC1SWOPhJZcduVvtjAu2HxmuVmgvfFUDIa0Q+J5WCLOr1H8CDPIHBeSn DDurqJPazO93UxInBFuLo59U7vzner16WtysJ4QBtEplG8gmn67HFaGWE3v9RX2+oKZGtzbVc FVEoInlFRg/IYP3nVXy0iKxunfXCL0ZbPJ2OebVZgvabzU1aULenwYlfd7bAKpM2DHDKdgP8w JlMCXClTJSs9CMwP7jyG6Uf/u/m6DYUyrvHt2YuaHIUW3T3Wi/2r6VCQ6TGa1NPg5zqjLv6qb AZU3i7Mq8iDyE5+oPqnnYQv9GN3dIXoSsqNI4/SVJVMOf7yrOS8fcoJW2DA01w81/PxTh70cm nyMk1bn31MIOIKDah98cCOiV37zj1S2Y8KOhcF6d0bk5fJzdvctUj+0S5sRHTrWB9yQ9fl3QA gtrzT8IFp94zx6+ts9MWqoFpnk3zxjz8/y3gOCNGeCH47XCmyroeytHXBlBSP4YTrIKYtLtNC uZaOh4agU+nIEWQlugHDXC3dOD8qM6QDrTd5JnRVjO1ti5kIGzrdyA/dhbS6tGScE86V4u8Qo iGaKxlDQ2FVF16GZIzknzj2KakJNKdhgJG42SQGFzHJuVdRBTHnZqHulb1Uw050pUJTSyri1K cOY9gv4nE1w== Archived-At: Subject: [xml2rfc-dev] formatting , was: [xml2rfc] [Rfc-markdown] New xml2rfc release: v2.12.1 X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 07:20:26 -0000 On 30.10.2018 08:20, Julian Reschke wrote: > On 2018-10-30 07:29, Henrik Levkowetz wrote: >> >> >> On 2018-10-30 05:57, Julian Reschke wrote: >>> On 2018-10-29 22:57, Henrik Levkowetz wrote: >>>> ... >>>> Country-specific address formatting.=C2=A0 Without it, you'll be stuc= k >>>> with the >>>> fallback, which is very americentric for the text output, somewhat >>>> less so >>>> for the html output (but not very refined).=C2=A0 I'd hate to see it = go. >>>> ... >>> >>> Example? Smells a bit like overkill, given that v3 has simplified >>> address formatting (postalLine). >> >> Example: In Norwegian and Swedish address format, the postal code goes >> before the city, not after the region code.=C2=A0 This is correct: >> >> =C2=A0=C2=A0 Midtskogveien 18 >> =C2=A0=C2=A0 2020 Skedsmokorset >> =C2=A0=C2=A0 Norway >> >> The current html specification would instead have produced, depending o= n >> how you work around its problems, one of >> >> =C2=A0=C2=A0 Midtskogveien 18 >> =C2=A0=C2=A0 Skedsmokorset >> =C2=A0=C2=A0 2020 >> =C2=A0=C2=A0 Norway >> >> or >> >> =C2=A0=C2=A0 Midtskogveien 18 >> =C2=A0=C2=A0 Skedsmokorset, 2020 >> =C2=A0=C2=A0 Norway >> >> which is a slighter degree of mangling than for places like various are= as >> of Japan, that needs city-region.=C2=A0 Here is a Japanese example.=C2= =A0 This is >> correct (except that it's also a translation, not just a romanization): >> >> =C2=A0=C2=A0 Japan >> =C2=A0=C2=A0 112-0001 >> =C2=A0=C2=A0 Tokyo-to >> =C2=A0=C2=A0 Bunkyo-ku >> =C2=A0=C2=A0 4-3-2 Hakusan >> =C2=A0=C2=A0 3rd Floor Room B >> >> and the RFC7992 specification would have rendered it as either this, >> preserving the semantic labelling of the parts, but loosing the >> city-region >> part: >> >> =C2=A0=C2=A0 3rd Floor Room B >> =C2=A0=C2=A0 4-3-2 Hakusan >> =C2=A0=C2=A0 Tokyo-to, 112-0001 >> =C2=A0=C2=A0 Japan >> >> or would loose all semantic labelling through forced use of postalLine >> for >> all entries. >> >> This problem has however been solved to a large degree by modern >> libraries. >> If you can do this *right*, why continue to do it wrong? > > Because it's complex, and now you are relying on a specific > implementation. Is the algorithm documented? > ... Coming back to this because I'm looking into how much it would take to implement it. Apart from complexity, my concern here is that the output now depends on a library that is specific to a certain language. If you can point to a definition of what that library does, it would be less of a concern. Looking at : > 3.1.13. In Section 2.37, > > The enhancement to , adding a element, is a fair > step on the way to permitting better representation of the wealth of > postal addresses around the globe which don't match the American > postal addresses. > > Unfortunately, it manages to throw the baby out with the bathwater by > constraining postalLine to be used only if none of the other elements > are used. This makes it impossible to apply hCard [HCARD] labels > (based on vCard [RFC6350] properties) to the elements of an address, > as [RFC7992] requires. Applying the schema from [RFC7991] would make I agree that there's a disconnect between RFC 7991 and 7992. However, I would prefer to solve that disconnect by just removing the hCard requirement from RFC 7992. Is anybody aware of any real-world code that actually processes that information (and can demonstrate it with an example)? (Disclaimer: rfc2629.xslt used to produce hCard information 14 years ago () but I removed it due to complexity and unclear benefits 6 years ago). > country information and hCard tags unavailable for any locality with > a postal address scheme that needs to use because it > does not match the American scheme. This would make statistics such > as the author origin statistics either miss authors with such > addresses, or make the statistics harder to compile than is > necessary, and make for instance the data on this page skewed: > I note that this page currently works based on the text versions. That said, I agree that if we want these stats, they should be easy to extract from the XML. The current proposal however seems to be a bit over the top to me. > The current implementation maps to the hCard property > "extended-address", and permits it to be used together with other > elements, in particular , , and . This is a > change to the schema. > > The current implementation also provides a full set of hCard- and > [RFC6350]-compatible address elements, including and > . The hCard locality address component is mapped to the > current element, however; not renamed to ''. I note that the implementation notes do not describe all new elements, nor how they are rendered. Looking at the currently checked-in grammar (): > postal =3D > element postal { > attribute xml:base { text }?, > attribute xml:lang { text }?, > ((city | code | country | region | street)* > | postalLine+ > | (city? > & cityarea? > & code? > & country > & extaddr* > & pobox? > & region? > & sortingcode? > & street*)) > } This defines cityarea, extaddr, pobox and sortingcode. We need descriptions of these. I also note that the grammar now has three different content models for , and whether a given source instance matches the first (classic) or the third (new) seems not to be always deterministic. If this is kept, we should try to reduce this to two cases. Best regards, Julian From nobody Fri May 17 01:07:30 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E721120157; Fri, 17 May 2019 01:07:22 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 UwdGHKtKj6dF; Fri, 17 May 2019 01:07:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDB812012B; Fri, 17 May 2019 01:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1558080424; bh=DnpWpvsIRei7URgS1uMsYKsNl37UqcDT0myFdJ7EVas=; h=X-UI-Sender-Class:Subject:From:To:Cc:References:Date:In-Reply-To; b=Lw3mkJjFdTxdj/WtUc9lZTLMx+J2fS/ln0NRBOpjVdYWAEPoXOxCXPufgsKzPWhqx YXbc2wzQGSZEIjBJs1MK6oIe1yO8ifxCM1vFj0vTz28mWwXNP0LvEYdrHPC7gjeKTh pOl6NLj+lrGsOFGsBFXwp/qOs+TDqd51ziyvqPZ0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M2t0Q-1gZAac2jPK-00sehw; Fri, 17 May 2019 10:07:04 +0200 From: Julian Reschke To: Henrik Levkowetz , Miek Gieben Cc: xml2rfc@ietf.org, xml2rfc-dev@ietf.org References: <20181029204446.xwjkdfdpj7sbhvsr@miek.nl> <0455bd48-3392-bb4c-f510-c57489792606@levkowetz.com> <20181029214325.5i3rrv55dpamvbsa@miek.nl> <1d03c466-bd4a-934e-18f0-f9ac5bc2225e@gmx.de> Message-ID: <69fbbcfc-f700-7f1a-9ea4-20de0f7bf4ff@gmx.de> Date: Fri, 17 May 2019 10:07:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:yPCO7ivnNB0j6eAQZ3mWet1p1L7Uy95rCZF/jYY0eieNdO4T8Xn HXEkPt331qckvSuBrQ5F8fLAkv23giMM0+vUCfCgflFR9Fe3CspaaJ71pb+Z7peAkCmHyKo HIzfd2pmw/C8BOrPoEnvFpgAdNosPI7+sfq+i4OTtZM87SVl2y1TeDMRNgBLbPIX/DzD1tU jkciATgjK1crYTWMvmp5Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:472KOZiH76g=:NDLPPD/d0k6tb9qQJYA0jj RsWEF/X7WRTlm00zqN9+YKOQCl3C0gg41neH+0YykdvN4Ybk7QQ7dwqwQc02US3PFl+S5nVXm 7pqL58jZQXkcmq6sMwcNJ98uR9vsPnw0vhJF3M4n79jpgDq9Cw81co/ctu0rRnTGhqtPRV49k qUFu+LuEP/RILlzxW2o5rkNv5ENIsv9qtwVn296ykRL1KBtcutU/XPXSjpmr3VnhiqUjTK632 ky/kC+YQclYkY4s+wyVbCRGX9HA4abwb/MS/ysM9hxYFbDWQ4ZKXDw6mW4Swr3VKJxjpDT9eq wy9gKPjK1MrgK2ObdRXVVgGeWL9R7tFG++LO8BC7gPYOoEpyhhaD7cP5ck3pqoGgsdFnD8UIs f/IGq2gh90oGMezna3oTIyZNkO593s2BcuMyxehg0DTwiRt0PfmgyuCeuqgWT3eymfjLaJvSX EeIB+dLcEYb2STnyAnfQSaqrt9bkcV2+hCi9KMsKdYbAf7Xh8GUjQv+acH9F2BeDU9Y8VYUzo DBIRFnZSuQomHHe0IqXaAM8X/2Mj8db++coBR6Qr+JtgloLeYCtlCTfaJwgWfbN6Cpim2cq+h zCeGZ6D8QsmrTjEGXpfpv7HjDysrzjfpyMkmETCvi2+fTe3DguKnbKe6b5zg1SE9PBeI1PxvG nzs4NC8ekdiDNRBQgNr6oE2V2x3bMygzG/4+T16yIOlmnrgPERzPrSZOAbIP9ziMKCGnrbq7g HVQDbd/ZtFYNOged8bDPJ8h+Xw+JpdS6RsgKVPxQGneczm2tR+v5JpGhQ6eG3egXToarYoR/x a7JiFd2op8njztInmTcmT1rxcAFcKmKKX30l1AddqaxL6Tsd42ncK3n0EWXpfJliyPOaOcDcS uyg9GmN9PMC7zxRtQg66GENsbwhSRDozTU75kRR9UFjEj58RaBHbIGb0QHZisBOU9NzXW4sMy +I7/UhzxKSjfm8z7Z8zYK25cGS/4isOKUTkuRoe1R4YNHEMo7vDcS Archived-At: Subject: Re: [xml2rfc-dev] [xml2rfc] formatting , was: [Rfc-markdown] New xml2rfc release: v2.12.1 X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 08:07:23 -0000 On 15.05.2019 09:19, Julian Reschke wrote: > ... > Coming back to this because I'm looking into how much it would take to > implement it. > > Apart from complexity, my concern here is that the output now depends on > a library that is specific to a certain language. If you can point to a > definition of what that library does, it would be less of a concern. > > Looking at > : > > >> 3.1.13.=C2=A0 In Section 2.37, >> >> =C2=A0=C2=A0 The enhancement to , adding a element= , is a fair >> =C2=A0=C2=A0 step on the way to permitting better representation of the= wealth of >> =C2=A0=C2=A0 postal addresses around the globe which don't match the Am= erican >> =C2=A0=C2=A0 postal addresses. >> >> =C2=A0=C2=A0 Unfortunately, it manages to throw the baby out with the b= athwater by >> =C2=A0=C2=A0 constraining postalLine to be used only if none of the oth= er elements >> =C2=A0=C2=A0 are used.=C2=A0 This makes it impossible to apply hCard [H= CARD] labels >> =C2=A0=C2=A0 (based on vCard [RFC6350] properties) to the elements of a= n address, >> =C2=A0=C2=A0 as [RFC7992] requires.=C2=A0 Applying the schema from [RFC= 7991] would make > ... FWIW, I just recalled *why* it is so. In RFC 2629's DTD, the content model for made the ordering of child elements significant, so in theory an author could at least have specified the elements in the order that is correct for the country the address is in (see ). However, the *implementation* (v1/TCL) did not respect that. Thus, this could not be changed without breaking existing output, and so that's what we have today. was introduced as *alternative* which has this ordering guarantee. However, that meant that it couldn't be easily fitted back between the existing child elements. Hope this clarifies how we got where RFC 7991 stands. Best regards, Julian From nobody Fri May 17 07:35:41 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2EA120103 for ; Fri, 17 May 2019 07:35:40 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 NTtJA46EA3rk for ; Fri, 17 May 2019 07:35:38 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC23E12008D for ; Fri, 17 May 2019 07:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1558103734; bh=7zYLIvuEIy/cPUjH7+R45p1Vuf0YmPlls5Jftsiidkg=; h=X-UI-Sender-Class:To:From:Subject:Cc:Date; b=iymfkvMHXw9pNQN+hMZ0X38BSXRSAmwUunu5B5c9IsisD2Fiow3blHGwOVyWu2fYk VZqLnDbXynXdx+cNhPjaqInhAm5ymC1N14U1hJgjleYXG5rbGtXF9iyS8Wb5DJQBDD G36EI85y7ZeoK4lunKi/EpwIB8v4LMB4/xsua45o= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LaKaw-1gxIHA1zmY-00m1Ob; Fri, 17 May 2019 16:35:34 +0200 To: XML Developer List From: Julian Reschke Message-ID: Date: Fri, 17 May 2019 16:35:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:tsiyuwqcZXJ+c45wPPRunCVcZdPaZ2lGYRhCWBVpive2DfH7csJ feRiBOCROQUtoWR1gqjCgYo5Embzb0PSJigqLOAoXOOx5z71f0XY6ReM05ZSdFYdGNSQgRW jJKCi/KvXYTyl4ehxqC8K1zySDWZXmkeXUt0kyMkXU3B3yPKCnVfWxyXuDi50eT83R9jpqJ GcXjRA2b+LbsGReicMyyg== X-UI-Out-Filterresults: notjunk:1;V03:K0:yKKP4nRlmWU=:U6TbbvVYniQ5qu7b99B7p6 hlT44QLzfmTB8Zow7Z53GcLdd6KnHYSCMQUc8yjVWC7X5JfYe5jICLriDKFMgz3QrvxDSTqlp aFM2QJVBWhwsnMxHLg4GJBZ3NBKihBUtp79kcHK9hUhRhIxlvpApm8cxHLr0agNAwcn/27khi QFZhvHiouowT9Cs55HE6ji4+ehq0vOXOp9q6T7FbeT6NmU8iCL9Motg7mdIDjpE1LsdqihycA gJBbPp71UgGQzA/lKG7i6LRLbRK/uXyirVqQagdT88XHy15kN+cCui0JvInJ/YNyI2XVcgt27 DGClZR+t4i8fiuk9RXcxff/ZV3agniG3qZc8amqcKMmZZDEoK97HSgrsNApNxqNM9tgNKxTTc PQpXDCFxCW85ixEuc4RwziLHnujGovAmOTAEChatMNjm7gDIJJyn1SWBSLZib4WdysPnLz2ZX spq4xvBH4OpHTYLgJyheBhJOVGT/iZE6npYgG1qzefJw6CEDDTmna6ci3iC5G+KmGVdFQ+6cZ bRxeGgQxYt7amAfTPYEBJj2T2XZsPRn4KpKkcny6USfJGlH2+lSVtJPnLM4a00gT/g/hgn06Q 0ZqdB08hvu41Tfu+S33czx5MSFsBjWjn/3uUOP+fZDAqyohAdNrCUqOc4M2Lkl3umi/THMtR9 n72lCKkgtEABJLDTLm4EedYHgmZFUFJuA6PgkY5is0O9xwqTbaIVOoQHk9Afqya7FwQeg+TJq kG0VGh1hh5MhYL2JjKIfYooySnIvbmg8v+RoEmJEvwHw9DF2pvLFp/O0LH4CafuzArhxKW0I2 bOQwr+5IiXcU4MRJygwoFUTjAMTPfY3mOWpTBfIMCQ3Bqpq9mImYN8Jv9ZlE5jke9Us9Kkc6C X2emiOkXA2uMTQr7uHap6TZO+pjV7VYIrsYWUpuU4qLUzW/5cm8X1X/H4ABNmEdshePdX5hSL c1WjE0m5ZZxcDUTay6+1DA8TtzWrTxkl+p24TMIXlwQ2cFuadPUby Archived-At: Subject: [xml2rfc-dev] feedback on X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 14:35:40 -0000 Hi there, so I stumbled across the element , used in the test file elements.xml (in the svn repo). Source: > > IAB > > The Use of Non-ASCII Characters in RFCs > > > > > ... > > > > The text output is: > [RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in > RFCs", IAB, RFC 7997, DOI 10.17487/RFC7997, December 2016, > . Removing it yields: > [RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in > RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, > . ...so the contents is inserted between title and series information. Question: is there an actual requirement for this? I checked the style guide and related information and could not find anything. *If* this is indeed needed, my preference would be to name/define the element more general terms; not in a way totally specific to IETF document= s. Best regards, Julian From nobody Wed May 22 18:00:02 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954E112011B for ; Wed, 22 May 2019 18:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gp1nIAUou0s for ; Wed, 22 May 2019 17:59:58 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C1612008F for ; Wed, 22 May 2019 17:59:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 01D521C163C; Wed, 22 May 2019 17:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GD2k0Cm-wd0b; Wed, 22 May 2019 17:59:30 -0700 (PDT) Received: from [10.198.42.44] (c-71-231-216-10.hsd1.wa.comcast.net [71.231.216.10]) by c8a.amsl.com (Postfix) with ESMTPSA id AB22C1C1505; Wed, 22 May 2019 17:59:30 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-1F8AF8C5-E5EA-40D7-ABC7-5C60D8B14484 Mime-Version: 1.0 (1.0) From: Heather Flanagan X-Mailer: iPad Mail (16F156) In-Reply-To: Date: Wed, 22 May 2019 17:59:56 -0700 Cc: XML Developer List Content-Transfer-Encoding: 7bit Message-Id: References: To: Julian Reschke Archived-At: Subject: Re: [xml2rfc-dev] feedback on X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 01:00:01 -0000 --Apple-Mail-1F8AF8C5-E5EA-40D7-ABC7-5C60D8B14484 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian, > On May 17, 2019, at 07:35, Julian Reschke wrote: >=20 > Hi there, >=20 > so I stumbled across the element , used in the test file > elements.xml (in the svn repo). >=20 > Source: >=20 >> >> IAB >> >> The Use of Non-ASCII Characters in RFCs >> >> >> >> >> ... > >> >> >> >=20 > The text output is: >=20 >> [RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in >> RFCs", IAB, RFC 7997, DOI 10.17487/RFC7997, December 2016, >> . >=20 > Removing it yields: >=20 >> [RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in >> RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, >> . >=20 > ...so the contents is inserted between title and series information. >=20 > Question: is there an actual requirement for this? I checked the style > guide and related information and could not find anything. Right. This (the addition of stream in the reference) is something I want to= start doing, but haven=E2=80=99t been able to because the current tools cou= ldn=E2=80=99t support it. See section 4.8.6.2 in https://www.ietf.org/archi= ve/id/draft-flanagan-7322bis-03.txt. >=20 > *If* this is indeed needed, my preference would be to name/define the > element more general terms; not in a way totally specific to IETF document= s. >=20 >=20 While I like the idea of generalizing, this is one area that I think truly i= s unique to our document series. Do you have a proposal for naming/defining i= t in another way? -Heather --Apple-Mail-1F8AF8C5-E5EA-40D7-ABC7-5C60D8B14484 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Julian,


On M= ay 17, 2019, at 07:35, Julian Reschke <julian.reschke@gmx.de> wrote:

Hi there,

so I= stumbled across the element <stream>, used in the test fileelements.xml (in the svn repo).

Sour= ce:

   = ; <reference anchor=3D"RFC7997" target=3D"https://www.rfc-editor.org/info/rfc7997" quote-titl= e=3D"true">
 = ;      <stream>IAB</stream>
       <= front>
  &nb= sp;       <title>The Use of Non-ASCII Ch= aracters in RFCs</title>
          <author full= name=3D"Heather Flanagan" role=3D"editor">
         <organization= />
    &= nbsp;     </author>
         &= nbsp;<date year=3D"2016" month=3D"December"/>
<= blockquote type=3D"cite">... >        <= ;/front>
  &= nbsp;    <seriesInfo name=3D"RFC" value=3D"7997"/>
     &nbs= p; <seriesInfo name=3D"DOI" value=3D"10.17487/RFC7997"/>
    </reference= >

The text output is:

  [RFC7997]=  Flanagan, H., Ed., "The Use of Non-ASCII Characters in
     &nbs= p;       RFCs", IAB, RFC 7997, DOI 10.174= 87/RFC7997, December 2016,
=            &nb= sp; <https://www= .rfc-editor.org/info/rfc7997>.
Removing it yields:

  [RFC7997]  Flanagan, H., Ed., "The Use of Non-A= SCII Characters in
&= nbsp;            = ;RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016,
       = ;      <https://www.rfc-editor.org/info/rfc7997>.
=

...so the contents is inserted between t= itle and series information.

Question: is t= here an actual requirement for this? I checked the style
gui= de and related information and could not find anything.

Right. This (the addition of stream in the refe= rence) is something I want to start doing, but haven=E2=80=99t been able to b= ecause the current tools couldn=E2=80=99t support it.  See section 4.8.= 6.2 in https://www.ietf.org/archive/id/draft-flanagan-7322bis-03.txt.=


= *If* this is indeed needed, my preference would be to name/define the=
element more general terms; not in a way totally specific to IETF d= ocuments.



While I= like the idea of generalizing, this is one area that I think truly is uniqu= e to our document series. Do you have a proposal for naming/defining it in a= nother way?

-Heather

= --Apple-Mail-1F8AF8C5-E5EA-40D7-ABC7-5C60D8B14484-- From nobody Thu May 23 04:48:37 2019 Return-Path: X-Original-To: xml2rfc-dev@ietfa.amsl.com Delivered-To: xml2rfc-dev@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3A912008B for ; Thu, 23 May 2019 04:48:36 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 aO1W3VwpdLyS for ; Thu, 23 May 2019 04:48:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F1912002F for ; Thu, 23 May 2019 04:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1558612110; bh=jCMNBlnBkHFPA6jI367mFAz6++hEhRO5uCW3sWGlQYI=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=fsK5+7RRz7TTaheno2Ey21xTWv7tqKKjHMjf/iWtRuvGoLfPkmuFbrU7JWI+kqYfx xKl3MpmIg0ogE/lbmGROFsaekhQHI8/U32ojHdGMgo8UcdB20AdvT/r+9zWNBYxDCD 5RlZTQe8duTbLdkt42FTmPD3QVXP1Hdts1ryXz1c= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mlf0U-1gl8042f4M-00inNd; Thu, 23 May 2019 13:48:30 +0200 To: Heather Flanagan Cc: XML Developer List References: From: Julian Reschke Message-ID: <7c8e5f51-0005-0020-a38e-8fa9026cda03@gmx.de> Date: Thu, 23 May 2019 13:48:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:bUl0y4fsIlJxRmo4kqe1MagYF0pfT6WJskJo+MWdgOCZ3cXjsHJ sn8d+meYnwsf7aLsTGqw48MiQfURKRrPeyK6hsaWCEw98N027CtBwWVQGdDuZv/2aKtzxSn 3NIyjCjrUzph14sWE/32p3r0g9/fJferXmx1VboC4ckggrLG8/s43bw4Suxh0UESjVFD1s6 GwxmZweJEqWjf54C+agMA== X-UI-Out-Filterresults: notjunk:1;V03:K0:80Ekvpr8CG4=:SnNUoRHTa81C8CRUbQXiUx sImWRsfuX8Yf3dpqixIeQIFUoQGnxVtplnsvhHmHY83OIUbcAwMHXuS7VMlAP34uVgO63MYhZ LlZU0CYd3YcjxjQuTL19v5zbWt4KgMIbl15CYi1qic1CsMsBhgpAVA7wA/bctpDFkP04pYnkg KDvCUeE8GN1AhY3175XLNoCgV/mfZrzr1U1j6ha3LLq1OD38Gw3UAk7TaC2YTsoa7GMxF//vO kp32+mVGJ4jlIzpBuoKqsFqA/bPtnzCwsY+OQ9l3YPwX5ckpKf1IqRuA/P8gfKGBQswQ94WQp TBTxbJkQf7RhhzQl1dYyuuui09/SbMx1wS0j4i2br1ePVEjky4sqIgYql+6LRhdZHxPcy4XA5 qLt9IXgmrbliin9Q1BZYmqRUbnwDQduDxYPxO+5DCdi4tuwnbBVN/Uscg6ZvJNSrtj6eyxUlr 4y+rLYVzJgGDohOCP0JczdB6UFmohHVKPVarDhyKSMd/a5C+bhT9pAOd2ZHeYGZWndYoiotkE EBLYNkql7oxCZscdiJ853ad4bObLll/9VyFXyDmb4pontEyZSpvBbUDz87YpZqnYqOz/9dQ4s 6a/4DwqW39Nc45c6YUZDRGp6FPpNzIZkoX9yPm81E8xZKl/hasQnTithABMAkoRQ9G94aaqPA k1Ay0E3DXHiF8DhkVUJCKSlAAMUlzOmbWKF+8owy+UYz5/MNTapr5kqxZjaAw/dPiHLToM1n4 5TLhG1K7u9WvoZCtKze+hOIsBwEX22xfF63pS5bMkR/ROwDepqLvwPYwIaeo818XNvhLqE1T5 K6UdYrdR6ou67I8fIFVfe3d0WhCDPvG1MNOEfBo5NGOGAauE8Qv1aHcDqdCPS0tnn15huG8q2 w/Vs+XmywFvHf0Ng3ZKHDJqSdKSywOG8QBfQ/g2TfSHboHuE0Rc8kmE5Bmtu8G+chh4QxEWGy 4xO73eLKHJTP50QBmtf/WMuv/wXNLrdX6E+bcGVFL5RBtkHoCCI5J Archived-At: Subject: Re: [xml2rfc-dev] feedback on X-BeenThere: xml2rfc-dev@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about particulars of xml2rfc V3 design, development and code." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 11:48:36 -0000 On 23.05.2019 02:59, Heather Flanagan wrote: > ... >> Question: is there an actual requirement for this? I checked the style >> guide and related information and could not find anything. > > Right. This (the addition of stream in the reference) is something I > want to start doing, but haven=E2=80=99t been able to because the curren= t tools > couldn=E2=80=99t support it. =C2=A0See section 4.8.6.2 in > https://www.ietf.org/archive/id/draft-flanagan-7322bis-03.txt. Ah, interesting. So this is something that goes between the title and the series informatio= n. I note that in V3 we already added (https://greenbytes.de/tech/webdav/rfc7991.html#element.refcontent), and documented it to go between title and date. Unfortunately, this is under specified, because it doesn't say whether it is before or behind the series information. I raised for tha= t. Note that the rational for was actual abuse of seriesInfo, such as in: > rfc7001.xml: > rfc7002.xml: > rfc7005.xml: > rfc7006.xml: > rfc7015.xml: > rfc7019.xml: > rfc7019.xml: > rfc7019.xml: > rfc7021.xml: > rfc7021.xml: (from AUTH48 XML...). (Note that I see much more of these for recent RFCs, which may indicate that the style guide requires output we can't produce...) That said, the *intent* was to place this *behind* seriesInfo, and this is what rfc2629.xslt does. xml2rfc on the other hand places it *before* series information, so in that implementation seems to do exactly what already does. Generally, this is a similar problem as the one that we've been discussing with respect to (for which I'd really like to see feedback). The content models of and do not reflect the actual order in which things get rendered, so it's somewhat hard to extend it with new elements that are guaranteed to show up in a specific place. From what I see, we'll need some way to insert additional content both before the series information and after it, and that could be done with - multiple elements - a single element with some control of placement The latter seems to be more logical to me (and also would scale better if we'd need another type of placement). So my proposal would be: - fix definition to say "by default: after series information= , - add attribute to select placement, for instance: IAB Now going back to the actual requirement in : > The following format is required for referencing RFCs. The Stream > abbreviation should be used; when no stream is available, as with > legacy RFCs, this may be left blank. > > Note the ordering for multiple authors: the format of the name of the > last author listed is different than that of all previous authors in > the list. > > For one author or editor: > > [RFCXXXX] Last name, First initial., Ed. (if applicable), "RFC > Title", Stream, Sub-series number (if applicable), RFC number, RFC > DOI, Date of publication, > [1]. This looks ok to me if "Stream" is one of IETF, IAB, or IRTF. But what about the independent stream? What should be displayed in that case? Best regards, Julian