within from oneOrMore to zeroOrMore, in order to make it possible to honour the tocInclude setting, and reordered some true/false entries for consistency, and changed the line breaking of some lines in the RNG compact representation to fit on 72-character lines. * Added .rng and .rnc files with the RFC7991 schema, in order to be able to automatically determine which elements and attributes are new in the schema since 7991. * Added a new writer, 'doc', and template and text snippet files for autogenerated documentation. * Updated the requirements file with some new module requirements. * Refactured the code a bit to make it more straightforward to generate text without writing it out to file. * Moved the list of deprecated attributes to writers/base.py, and did some slight refactoring for consistent naming of some class variables and avoidance of duplicate parsing of the schema file. * Did some minor code cleanup and dead code removal, and corrected the header generation for non-IETF documents (using ). * Fixed an issue where XML parser errors could be reported for '' instead of the actual input file name. * Added new options --docfile/--doc and --manpage/--man, used to trigger generation and display of the built-in documentation. Reorganised the option grouping. Updated some option help strings. Made it possible to propagate all command-line option information to the documentation template. * Corrected the default templates path. This is related to change [3723]. * Reverted a change from [3722] in the v2v3 converter. * Added a custom Jinja2 filter 'capfirst()', for use in the documentation template. * Tweaked the documentation template: Some changed wording, support for sub-items not wrapped in , corrected capitalisation using the 'capfirst' filter. * Updated hastext() and iscomment() to do the right thing if given content with embedded xml processing instructions. * Tweaked the handling of default values for --date, so as to give better documentation of the option, and also tweaked the help text for --table-borders. * Added a class utility method to get any current PI related to a given setting, and fixed another case of template path default value, related to [3722]. * Added PI support for text table borders setting, and improved the text table output for transitions between

and

rows> for 'light' and 'minimal' borders. * Added makefile support for testing of the --manpage and --docfile switches. Added silencing of one unavoidable warning in the test of --unprep. -- Henrik Levkowetz 17 Jul 2020 14:07:39 -0700 The preferred way to install xml2rfc is by doing 'pip install xml2rfc', and 'pip install --upgrade xml2rfc' to upgrade. If there are system- installed python modules which pip will not upgrade, you may have to use 'pip install --upgrade --no-deps xml2rfc' and install dependencies manually. The new version is also available through SVN checkout, with 'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.47.0' Regards, Henrik (via the mkrelease script) From nobody Mon Jul 20 08:18:25 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDB93A0C3C; Mon, 20 Jul 2020 08:18:09 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BAE4-HaLS8R; Mon, 20 Jul 2020 08:18:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03CD3A0C37; Mon, 20 Jul 2020 08:18:07 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:53993 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 1jxXYL-0000nr-GY; Mon, 20 Jul 2020 08:18:07 -0700 To: Tools Team Discussion , IETF References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> Cc: rfc-markdown@ietf.org, xml2rfc@ietf.org, xml2rfc-dev@ietf.org From: Henrik Levkowetz Message-ID: <82e10650-8f68-26b2-df22-dff93ce72ee0@levkowetz.com> Date: Mon, 20 Jul 2020 17:17:57 +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: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qxg1tUKcgKT89KbPNcC0ibiM6kxnJeAdE" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org, rfc-markdown@ietf.org, ietf@ietf.org, tools-discuss@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] End of support for xml2rfc on Python 2.x is coming soon X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 15:18:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qxg1tUKcgKT89KbPNcC0ibiM6kxnJeAdE Content-Type: multipart/mixed; boundary="JDSUCIUdHNDE0lSCX8dRkiAekR5oRA24W"; protected-headers="v1" From: Henrik Levkowetz To: Tools Team Discussion , IETF Cc: rfc-markdown@ietf.org, xml2rfc@ietf.org, xml2rfc-dev@ietf.org Message-ID: <82e10650-8f68-26b2-df22-dff93ce72ee0@levkowetz.com> Subject: Re: End of support for xml2rfc on Python 2.x is coming soon References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> In-Reply-To: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> --JDSUCIUdHNDE0lSCX8dRkiAekR5oRA24W Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, It's taken a lot longer than we thought, but I expect the next release of= xml2rfc to be 3.0.0. I currently plan to do the 3.0.0 release shortly af= ter IETF 108. Best regards, Henrik On 2019-10-08 23:23, Russ Housley wrote: > Heads up! >=20 > With the transition to xml2rfc vocabulary version 3, xml2rfc has gained= > the ability to generate PDF output when the necessary system libraries > are installed. However, xml2rfc runs on Python 2.7, but the library > needed for PDF generation ended support for Python 2.7 about 10 > releases ago. This means that the need to end support for xml2rfc on > Python 2.7 is becoming urgent. Another factor is that bugfix support > for Python 2.7.x itself officially stops on 1 January 2020, so we need > to transition away from Python 2.7 soon in any case. >=20 > The latest xml2rfc release is 2.32.0. There will most likely be one or= > two additional xml2rfc releases in the 2.x series, but after that, the > plan is to transition to a 3.x release series, with two major changes: >=20 > (1) xml2rfc will no longer run under Python 2.7; it will require > Python 3.5 or higher. If you cannot install and run Python 3 on > your system, the web service at xml2rfc.ietf.org can be used. >=20 > (2) The default output formatters will change to v3. The v2 formatters= > will still be available by using a --legacy switch. >=20 > Expect the first xml2rfc 3.x series release before the end of the month= =2E >=20 > On behalf of the Tools Team, > Russ >=20 >=20 --JDSUCIUdHNDE0lSCX8dRkiAekR5oRA24W-- --qxg1tUKcgKT89KbPNcC0ibiM6kxnJeAdE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl8VtaYACgkQTptXS4+7 Fxog0g//WBc6wwjIjmCEnK2dnnF20jKGE10ltiKROTjLR0U+mnJa3c7suSNAzbmq /v+mIOowNVTb6ZOGBSNTDHmn+yM9fF1Ezfmug9smLe4AITM88Cz6d4YLPnNBV6z8 aglcElWYgN883ixe2UkqLHApk/XR1FS5U9GPEXcXGGYr98xHKgHkn12xM0Zyz4If WU6BEdD74yQ6/uh1+JKGgY2awVjF2IRnV4khqM9ij9qPpmKLS2hBuPHkfH+31tQa KqiL1pVtr4LItX5OLk59sckuioj/j9WmohrrTvIucDHU7AL2c8Eusf9XGPN+jOH5 +oxbcvLAPlU6wb9N+W85rA08Y3nB2n22kTqwyCQKS4W+RKDRWxsM6N8ZsysI6tVL JTdR7o7WV7shYH4rSPKMCQrZlvl4FcmdGBZmedbQ4/qqnxsy64MNKDweEoAU95mJ 7CLey24zP2mSk8Iw4XJTtJTJkVVrVtwCX28GaCSnZ7htzqjB95WqruBspOvBPxKL VisVLmOKPGLLDtE1m7Nr8qaHtqu222S4QHZiTG2m3v3Z1a4NF/NSMi4+WX6OAH6Z Vmavkq/xmmsL4cZl9A/DmsZJWniex4SM7AKexup2bHUapKdKJ90/GmYyhNlPWGBp Q7Wlnm6g+H3CqSlXEJ2/sWc8g/BzLsoZTyJ3LJeQBC1C57JUEd4= =vZqV -----END PGP SIGNATURE----- --qxg1tUKcgKT89KbPNcC0ibiM6kxnJeAdE-- From nobody Mon Jul 20 10:41:34 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C4E3A0D8E; Mon, 20 Jul 2020 10:41:17 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CLQ8vZA1z6V; Mon, 20 Jul 2020 10:41:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD663A0D79; Mon, 20 Jul 2020 10:41:15 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:55815 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 1jxZms-0002Et-S0; Mon, 20 Jul 2020 10:41:15 -0700 To: Tools Team Discussion , IETF References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <82e10650-8f68-26b2-df22-dff93ce72ee0@levkowetz.com> Cc: rfc-markdown@ietf.org, xml2rfc@ietf.org, xml2rfc-dev@ietf.org From: Henrik Levkowetz Message-ID: <4f4adbcb-5b19-19ce-2465-8f49569e139a@levkowetz.com> Date: Mon, 20 Jul 2020 19:41: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: <82e10650-8f68-26b2-df22-dff93ce72ee0@levkowetz.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rJUhVg0f5EQdIifxHDfklsCJIeC4XupMG" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org, rfc-markdown@ietf.org, ietf@ietf.org, tools-discuss@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] End of support for xml2rfc on Python 2.x is coming soon X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 17:41:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rJUhVg0f5EQdIifxHDfklsCJIeC4XupMG Content-Type: multipart/mixed; boundary="6anOXQ8sElXNCks352w5EbKEJUoRFh1nA"; protected-headers="v1" From: Henrik Levkowetz To: Tools Team Discussion , IETF Cc: rfc-markdown@ietf.org, xml2rfc@ietf.org, xml2rfc-dev@ietf.org Message-ID: <4f4adbcb-5b19-19ce-2465-8f49569e139a@levkowetz.com> Subject: Re: End of support for xml2rfc on Python 2.x is coming soon References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <82e10650-8f68-26b2-df22-dff93ce72ee0@levkowetz.com> In-Reply-To: <82e10650-8f68-26b2-df22-dff93ce72ee0@levkowetz.com> --6anOXQ8sElXNCks352w5EbKEJUoRFh1nA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2020-07-20 17:17, Henrik Levkowetz wrote: > Hi, >=20 > It's taken a lot longer than we thought, but I expect the next release = of > xml2rfc to be 3.0.0. I currently plan to do the 3.0.0 release shortly = after > IETF 108. I've been asked to clarify whether the conversion to 3.0.0 will mean the end of support for the v2 (RFC 7749) vocabulary or whether that vocabular= y (DTD/Schema) will continue to be supported. Short: The v2 vocabulary will continue to be supported. The longer answer is that (as indicated below) the default _output_ forma= t will change to use the v3 renderer. xml2rfc will continue to accept v2 i= nput, but by default it will send it through the v2-to-v3 converter, and proces= s the resulting v3 xml through the v3 formatters. If you want to use the v2 formatters directly from the v2 XML, you will n= eed to give the --legacy switch to xml2rfc. Best regards, Henrik > Best regards, >=20 > Henrik >=20 > On 2019-10-08 23:23, Russ Housley wrote: >> Heads up! >>=20 >> With the transition to xml2rfc vocabulary version 3, xml2rfc has gaine= d >> the ability to generate PDF output when the necessary system libraries= >> are installed. However, xml2rfc runs on Python 2.7, but the library >> needed for PDF generation ended support for Python 2.7 about 10 >> releases ago. This means that the need to end support for xml2rfc on >> Python 2.7 is becoming urgent. Another factor is that bugfix support >> for Python 2.7.x itself officially stops on 1 January 2020, so we need= >> to transition away from Python 2.7 soon in any case. >>=20 >> The latest xml2rfc release is 2.32.0. There will most likely be one o= r >> two additional xml2rfc releases in the 2.x series, but after that, the= >> plan is to transition to a 3.x release series, with two major changes:= >>=20 >> (1) xml2rfc will no longer run under Python 2.7; it will require >> Python 3.5 or higher. If you cannot install and run Python 3 on >> your system, the web service at xml2rfc.ietf.org can be used. >>=20 >> (2) The default output formatters will change to v3. The v2 formatter= s >> will still be available by using a --legacy switch. >>=20 >> Expect the first xml2rfc 3.x series release before the end of the mont= h. >>=20 >> On behalf of the Tools Team, >> Russ >>=20 >>=20 >=20 --6anOXQ8sElXNCks352w5EbKEJUoRFh1nA-- --rJUhVg0f5EQdIifxHDfklsCJIeC4XupMG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl8V1zMACgkQTptXS4+7 Fxpi0hAAsznwUheHDsc5qDtPP2IAmSafUZrqggKxn+/goDc+O6NiRlHIajwp+RUv oLaa0eF5ELOAl6nqN/9Zmav3XzM7hpedkBT6taaSH7uWcQueH44OPp5zGmOvIpWs 2QDh54RvRX97WaVsOLuic6JwmIV+B19pRPF3lecZL26IvbLi37v6Nb1vo9ZVl4nJ OkDorWhzV6osvzCE2VSTGVb4OFdl9W2ToCZfTDCagUNQTirMm7kHvxfvMNTOAQkQ W72gmc7qY5/BC5Zix41xbRE/uub4Ruz7MZFID29e8zRIACLVYAT+ipVpinsnK3DN oPoXv8Cjjaev8Wnw4lS++L5KIjhOBsuT+i8ALwnE+0ENTQbCzu054AYinL/mUF56 7Z51pfwjdNfsdRBztCPY3sKC892GUMb2epONLByl2vN22gEgYzjY+a59S2D68dq9 pZWr8y3QxYaCljp8XBBnnl1oTrE927SCbCtsAU1o22aFUFNTnfI3EPMfZE05geX/ ngUbMDs5O+LEqUlSitkHTk3A1nFoBM9Sr3uQPvqBXuPy4Zt5RONHsAoOKTywXJzN hMdIySHBazCodOYIfH0M+zBppZXifrwyPv2a408hhfSBSufgJD1802YGfvHKwe/L GnYHNRnRygYjGKK8h4eUR2vc3IMTfaXMLSXiGnFmk6GNyGnwSzY= =jhHT -----END PGP SIGNATURE----- --rJUhVg0f5EQdIifxHDfklsCJIeC4XupMG-- From nobody Mon Jul 20 12:25:04 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEB93A0E34; Mon, 20 Jul 2020 12:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRRKPuOQvCl9; Mon, 20 Jul 2020 12:24:52 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C6D3A0E41; Mon, 20 Jul 2020 12:24:50 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B9WrX4kXDzyXk; Mon, 20 Jul 2020 21:24:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 $3608.120.23.2.1$) From: Carsten Bormann In-Reply-To: <4f4adbcb-5b19-19ce-2465-8f49569e139a@levkowetz.com> Date: Mon, 20 Jul 2020 21:24:43 +0200 Cc: Tools Team Discussion , IETF , rfc-markdown@ietf.org, XML2RFC Interest Group , XML Developer List X-Mao-Original-Outgoing-Id: 616965883.96795-cdae1ba58884b308ca21f79ef4572961 Content-Transfer-Encoding: quoted-printable Message-Id: References: <082EE9F1-D4AA-487F-BB8C-08CDB59C5A2F@vigilsec.com> <82e10650-8f68-26b2-df22-dff93ce72ee0@levkowetz.com> <4f4adbcb-5b19-19ce-2465-8f49569e139a@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [xml2rfc] End of support for xml2rfc on Python 2.x is coming soon X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2020 19:24:55 -0000 On 2020-07-20, at 19:41, Henrik Levkowetz wrote: >=20 > The longer answer is that (as indicated below) the default _output_ = format > will change to use the v3 renderer. xml2rfc will continue to accept = v2 input, > but by default it will send it through the v2-to-v3 converter, and = process > the resulting v3 xml through the v3 formatters. >=20 > If you want to use the v2 formatters directly from the v2 XML, you = will need > to give the --legacy switch to xml2rfc. Makes a lot of sense to me. The v2-to-v3 converter seems to work very well, and continuing to = support all the XML2RFCv2 files lying around (and still being generated) = is the right approach as well. Thank you, Henrik! Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 21 07:36:57 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1B13A093B for ; Tue, 21 Jul 2020 07:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 6Xkhb0QznymN for ; Tue, 21 Jul 2020 07:36:53 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2046.outbound.protection.outlook.com [40.107.237.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD873A0926 for ; Tue, 21 Jul 2020 07:36:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bihwqV5qVo8m1cM17DcqYhgp+hztn3j423VRBMhkfJcIoyRigwf1+cLT2rolHgJUbRIoYGrjeT0M6To2m5Wp8FGzTIlB8lM2+E8rUwByLuFygcMZxJnH2LX8DAwtCDjHiPSc8K9f8+cW9QIwmUbqfBuNBnXjP/349ghG0INyOzXPMXhG8iv2EIHgifLqfYTJmlqHukeMF9llrEg0+eOK/NMvn/N1FXiPhN/wHmjnVOyMr8d/rdQE8ECFpEsq/sxmS2QnAw5j4htWygd0dEVqR4A0Fm2z+cHm43GW/xhQVWAtksQoujFizxCBf247cdwdWWZlGIchNoK+9TYTNJ5wJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pz5IlEQOnZXG6ZlrM+dWfejFdQhsqKWiNx+rjAqOnEg=; b=irDM+UQbG8RpIzOpY83qp5P6DhqB6qLkvNRvxX17Vx5R5qOL7cNZZFcH3kp/uNFoDK8zp+d1XgcsdbV/XWYiM1Zf0IOk6WTGrLJipHVziYsfpq/OuVCz6j1roJJgOBSQe81dPh1ZIXyMn/L7kyKMMNCrOQP1IdlPbI0gllopE+YEjPlzuqXn/DDd/ux2Og6xgbBrv2pvumoTQc3LEZpAxZCivV/ULIa/3DFDVTbu9f5HaKfb0u/VH4v0t/fw6g4c4Z8nBa7gibiXumAEg2DUSvn6J0u63JuKs2Jevcb1dg3S1t2iRbcfMofiTqDEnYy9o/cYB2u4DvARhhgjP1gVRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pz5IlEQOnZXG6ZlrM+dWfejFdQhsqKWiNx+rjAqOnEg=; b=LEMid1r8GzuarU3uy1icFBFq1+oBgKGh0S3tgSU326nouBT9xuHZRv+M6UbBseYXrZnA3zuMHL++xef8PKD36/NXQLivivV+wkvhYf4Frn5DOefweGD/NKJthTlrMgsjLVBQO/Tb1DRQpsNhEvJJUFq2nBRPJ1+uuJYs6ZA285c= Received: from BL0PR02CA0020.namprd02.prod.outlook.com (2603:10b6:207:3c::33) by BN8PR12MB3602.namprd12.prod.outlook.com (2603:10b6:408:49::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.25; Tue, 21 Jul 2020 14:36:52 +0000 Received: from BL2NAM02FT054.eop-nam02.prod.protection.outlook.com (2603:10b6:207:3c:cafe::7d) by BL0PR02CA0020.outlook.office365.com (2603:10b6:207:3c::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20 via Frontend Transport; Tue, 21 Jul 2020 14:36:52 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT054.mail.protection.outlook.com (10.152.77.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.18 via Frontend Transport; Tue, 21 Jul 2020 14:36:51 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 06LEanw3011679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 21 Jul 2020 10:36:51 -0400 To: xml2rfc@ietf.org From: Paul Kyzivat Message-ID: Date: Tue, 21 Jul 2020 10:36:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(46966005)(26005)(7596003)(47076004)(2616005)(956004)(186003)(75432002)(82310400002)(5660300002)(6916009)(4744005)(31696002)(70206006)(70586007)(2906002)(83380400001)(8936002)(3480700007)(356005)(36906005)(31686004)(498600001)(8676002)(336012)(86362001)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 27301187-f872-4c91-425f-08d82d8381f2 X-MS-TrafficTypeDiagnostic: BN8PR12MB3602: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: hH+qIlhyGKN6PmdpwAohfWx4rkz5fRR+K2XKkb+lR21Qr4RIkSKjI65FDoyR1QleHJFUlyONHmiwq54u5qrOSvz3ldkluO2f+lQPsNV2DQ6XsLoie6kefiGyP4Wf9rQQmdjbOM4pVUDlorY9daeqsrVSejt9HT2zj1atoKsdRw19k6rDkovqu14JrYG5J1N2kI1ibYD6xhAx8ZmKR90FR38bvmUUvasv0McBPkj5bQ0zu6siihN66xDwgfMlzUWuK/I5Od89QB3IjUNul1kXCp4vToZGDcHvgED3KtKivxFobl8GP0BvuN+uAsPdHQnq9erW/i4iVCXEeUH2hWAh6Qi3faSp8Nm+PBfDfhVtR949XhI0QLZtuvfNCf0sI4AAF8rVqpYgSORAW36JTIALYzVMb9RLIXqzkjeldfRwGSmHvzyBMN5RoD6/7Dz8FmHm X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jul 2020 14:36:51.6418 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 27301187-f872-4c91-425f-08d82d8381f2 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT054.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR12MB3602 Archived-At: Subject: [xml2rfc] use of sourcecode type X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 14:36:55 -0000 I have a question about specification of type in sourcecode elements: In RFC4566bis there are many examples that have fragments of SDP. But they aren't compliant to SDP syntax, since it requires that many things be present - that are intentionally omitted from these examples. Is it valid to tag these with type="SDP"? (In sip we had a similar problem. There is a mime-type message/sip, but we sometimes also return fragments of sip in error messages. We ended up defining a separate message/sipfrag mime-type for this.) Thanks, Paul From nobody Tue Jul 21 08:10:25 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB84E3A0A0A for ; Tue, 21 Jul 2020 08:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFK2PhGwcARk for ; Tue, 21 Jul 2020 08:10:21 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3887E3A0A03 for ; Tue, 21 Jul 2020 08:10:20 -0700 (PDT) Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BB28V6Kg4z103j; Tue, 21 Jul 2020 17:10:18 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 $3608.120.23.2.1$) From: Carsten Bormann In-Reply-To: Date: Tue, 21 Jul 2020 17:10:18 +0200 Cc: XML2RFC Interest Group , RFC Interest X-Mao-Original-Outgoing-Id: 617037018.1169651-c3686bd7a4c6f65304a6a452a125e97d Content-Transfer-Encoding: quoted-printable Message-Id: <748F0BE8-5DDA-4CC1-9306-0C67F906C955@tzi.org> References: To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [xml2rfc] use of sourcecode type X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 15:10:24 -0000 A similar problem is giving examples that are intentionally bad in order = to demonstrate a kind of error. I typically tag them with a type that is derived from the one I would = give for real code, e.g., =E2=80=9CCDDLx=E2=80=9D for a bad CDDL = example. I think it would be good to agree on some way to indicate = this. A related problem is that often several code blocks combine to one valid = instance of CDDL, for example see Figure 1, 2, 3 in RFC 8428. There is = no way to say that Figure 1 and 2 combine into a valid instance, and so = do Figure 1 and 3, but not any other combination. And, by the way, those type tags are conventionally lower-cased, but = this is not made very explicit; you have to infer that from the list in = Section 2.48.4 of RFC 7991 or the RFC editor=E2=80=99s updated copy of = that list: https://www.rfc-editor.org/materials/sourcecode-types.txt (Ha, this doesn=E2=80=99t even have =E2=80=9Ccddl=E2=80=9D in it; I=E2=80=99= m not sure how this is updated and whether there shouldn=E2=80=99t = really be an IANA registry for these.) Gr=C3=BC=C3=9Fe, Carsten > On 2020-07-21, at 16:36, Paul Kyzivat wrote: >=20 > I have a question about specification of type in sourcecode elements: >=20 > In RFC4566bis there are many examples that have fragments of SDP. But = they aren't compliant to SDP syntax, since it requires that many things = be present - that are intentionally omitted from these examples. >=20 > Is it valid to tag these with type=3D"SDP"? >=20 > (In sip we had a similar problem. There is a mime-type message/sip, = but we sometimes also return fragments of sip in error messages. We = ended up defining a separate message/sipfrag mime-type for this.) >=20 > Thanks, > Paul >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Tue Jul 21 08:48:28 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672863A0B71 for ; Tue, 21 Jul 2020 08:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=alum.mit.edu 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 8b67LooMPi6n for ; Tue, 21 Jul 2020 08:48:19 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2051.outbound.protection.outlook.com [40.107.223.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A72D3A0B45 for ; Tue, 21 Jul 2020 08:48:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KdDmUnCdIjWZr9iBONAkW9V5RzSi4m6TeFT43YQwl4Gd4yeW0D0ABCN7YRL/ouKIg3o+5xeBJubDp0PerAKGSCaCywtx3dVlIYHaTEKWOUHIe/oF86rugQxGoOFvIPrw1/jVvLrESMAW3GvcCPojoQ6YCwPGkuLsdckAFNuGgDH+J2soLlsvN77tw+5TyW7CasxBIloSUmtwmKQYtI7JKiJqPqx1CiPCciDNqw871NIGoobevG74qi4i8T8rJ8JJ2aChDgrxlX4eBYe6t0zoIfoYxuUQGwTiwGtG3rhemGDP67bs0DRfWq8RLvdhzzk0eTy8hT8si3MPS0VPp80elA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ib/5VQ5T/nTiOP8tMOo8cWhQqdfzJMWPbxi3IrBsRBI=; b=TgQa39sjCmN4/Tc0za7QFi+owuFMe4vzLjxU5qqvm3wEgKV4fV4cfqxnV3lxdvufjPcAN8lrQffAa/BRm3LTR9M2G35Q3ZADW/SbwURGz4M6JGONK3OCt4yFudPh1LhYD67Lw7A5Pg1DSC9W7gFHNsXUfluzM/ym+qIJsILcY3Xd8lw7hT7L5M6XgqbuVnkzimThLq7RSTrhEXP4+YiKzY0P10XWpwPT//i7V2s/Mr4ZcHGVmRs7yk5iJk8Jw9mRMx/yVkWzZyUROLw8zOrH9VppPZAKHykh86BF/GONqPZb0xbklf9KPV35y/RgbhcE/Hu0Bl9B2eiKH2EKeE1E2Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=tzi.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ib/5VQ5T/nTiOP8tMOo8cWhQqdfzJMWPbxi3IrBsRBI=; b=hwfnc8Q9N2Oq206kzINGoUTVHmoOoA4DQBbdGtfKH17jXaE6JGvZbO+n7Ygc5rF1+8V/HrZb4Akv0cpqkGN+9qQlryTsBlg6zX9WaTuuA1c+TjxoMW4h0w5NEzSLmeu2o/Qs6Qc8ZPr0Bcz0OrKFd5JjfUoD+xLDSqakSRZ1+t0= Received: from MN2PR19CA0020.namprd19.prod.outlook.com (2603:10b6:208:178::33) by BY5PR12MB3731.namprd12.prod.outlook.com (2603:10b6:a03:1a7::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20; Tue, 21 Jul 2020 15:48:17 +0000 Received: from BL2NAM02FT062.eop-nam02.prod.protection.outlook.com (2603:10b6:208:178:cafe::f2) by MN2PR19CA0020.outlook.office365.com (2603:10b6:208:178::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.18 via Frontend Transport; Tue, 21 Jul 2020 15:48:17 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT062.mail.protection.outlook.com (10.152.77.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.18 via Frontend Transport; Tue, 21 Jul 2020 15:48:16 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 06LFmDj5016872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 21 Jul 2020 11:48:14 -0400 To: Carsten Bormann Cc: XML2RFC Interest Group , RFC Interest References: <748F0BE8-5DDA-4CC1-9306-0C67F906C955@tzi.org> From: Paul Kyzivat Message-ID: Date: Tue, 21 Jul 2020 11:48:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <748F0BE8-5DDA-4CC1-9306-0C67F906C955@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(46966005)(4326008)(86362001)(31696002)(31686004)(70206006)(70586007)(336012)(75432002)(956004)(2616005)(8676002)(8936002)(54906003)(498600001)(53546011)(186003)(26005)(83380400001)(966005)(47076004)(7596003)(356005)(36906005)(5660300002)(6916009)(2906002)(82310400002)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a4a32800-cd83-4e86-7eb6-08d82d8d7c03 X-MS-TrafficTypeDiagnostic: BY5PR12MB3731: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5516; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 2Ix8qla2Ov9T24nlu4fT/eu/tGTlTVUl0A3CyMvqwmszGQBd6B/UveXkJfiNOVye+ZoIPeJuRm4WRg2g0PF4E7ouLko3aNa/QxRL/5jb1J1aiT3KMUdhjymW/wtpp57jqerD6bPBU/an9SDiyDm6VCkeEFMAwmnO4WnljMzM8+6hRhK/m8F2oshj7OgOQBVlxE8TuLuIOHZ8VmS4YNm9cmsutmd+/Fznx+4aY8nJTNoxjKWa4va53x+ufZYk31PCKVQlWqd/nMspz6FjTvuGwr4upuEGs3rLdlrD4pkiBXFAKkNdBw9qAKV+jUOFRsq/ep+D0iYqEuB+XxAYFXtLqM74HXSD6hnvDZHgmNWO8I7MmjZdJILijljO+gpV3HLgIb/jEDfYsxq7Yz/n/vw773y+I20vdzFvMRsqxkZUqX9vzuRhQ2PWvOchfcI3tF5zDshQBJxefyqS6kCMLYKzPI4lZ5La67qvbX1ATVIBego0ueVb2kQyWhDWrluSF4Qe X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jul 2020 15:48:16.6258 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a4a32800-cd83-4e86-7eb6-08d82d8d7c03 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT062.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB3731 Archived-At: Subject: Re: [xml2rfc] use of sourcecode type X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 15:48:26 -0000 On 7/21/20 11:10 AM, Carsten Bormann wrote: > A similar problem is giving examples that are intentionally bad in order to demonstrate a kind of error. Good point. > I typically tag them with a type that is derived from the one I would give for real code, e.g., “CDDLx” for a bad CDDL example. I think it would be good to agree on some way to indicate this. I agree that we should have some agreed upon way to do this. Perhaps a "+xyz" suffix, with some agreed up xyz values. > A related problem is that often several code blocks combine to one valid instance of CDDL, for example see Figure 1, 2, 3 in RFC 8428. There is no way to say that Figure 1 and 2 combine into a valid instance, and so do Figure 1 and 3, but not any other combination. I'm also interested in this. I believe an obvious solution to this is via the "name" attribute. All the ones with the same name should be gathered together. A problem I have with both name and type is that they are invisible in the human readable formats. They provide semantic information that may be of interest to a reader. Perhaps they could be available in html via a popup? > And, by the way, those type tags are conventionally lower-cased, but this is not made very explicit; you have to infer that from the list in Section 2.48.4 of RFC 7991 or the RFC editor’s updated copy of that list: > https://www.rfc-editor.org/materials/sourcecode-types.txt > > (Ha, this doesn’t even have “cddl” in it; I’m not sure how this is updated and whether there shouldn’t really be an IANA registry for these.) For these to be useful for any sort of automated processing I think they should be standardized. I agree with an IANA registry. If we wanted to allow unstandardized usage there could be X- prefixes, but we have banned those many other places. Thanks, Paul From nobody Tue Jul 21 09:15:20 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170573A0B75 for ; Tue, 21 Jul 2020 09:15:19 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g08s8hZmwba6 for ; Tue, 21 Jul 2020 09:15:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D14823A0B72 for ; Tue, 21 Jul 2020 09:15:17 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:50741 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 1jxuvD-0005hs-VZ; Tue, 21 Jul 2020 09:15:16 -0700 To: Paul Kyzivat , Carsten Bormann References: <748F0BE8-5DDA-4CC1-9306-0C67F906C955@tzi.org> Cc: XML2RFC Interest Group , RFC Interest From: Henrik Levkowetz Message-ID: <9fbe057d-c820-2cfe-012f-dff4edcc03ca@levkowetz.com> Date: Tue, 21 Jul 2020 18:15:08 +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="MswB0rA1WHQAkcON4ulRHs4GboBBIERHb" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: rfc-interest@rfc-editor.org, xml2rfc@ietf.org, cabo@tzi.org, pkyzivat@alum.mit.edu 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] [rfc-i] use of sourcecode type X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 16:15:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MswB0rA1WHQAkcON4ulRHs4GboBBIERHb Content-Type: multipart/mixed; boundary="f5kxD7Qw5UWFrMGIiOfPWQkOT8mtblF8B"; protected-headers="v1" From: Henrik Levkowetz To: Paul Kyzivat , Carsten Bormann Cc: XML2RFC Interest Group , RFC Interest Message-ID: <9fbe057d-c820-2cfe-012f-dff4edcc03ca@levkowetz.com> Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type References: <748F0BE8-5DDA-4CC1-9306-0C67F906C955@tzi.org> In-Reply-To: --f5kxD7Qw5UWFrMGIiOfPWQkOT8mtblF8B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2020-07-21 17:48, Paul Kyzivat wrote: > On 7/21/20 11:10 AM, Carsten Bormann wrote: >> A similar problem is giving examples that are intentionally bad in ord= er to demonstrate a kind of error. >=20 > Good point. >=20 >> I typically tag them with a type that is derived from the one I would = give for real code, e.g., =E2=80=9CCDDLx=E2=80=9D for a bad CDDL example.= I think it would be good to agree on some way to indicate this. >=20 > I agree that we should have some agreed upon way to do this. >=20 > Perhaps a "+xyz" suffix, with some agreed up xyz values. >=20 >> A related problem is that often several code blocks combine to one val= id instance of CDDL, for example see Figure 1, 2, 3 in RFC 8428. There i= s no way to say that Figure 1 and 2 combine into a valid instance, and so= do Figure 1 and 3, but not any other combination. >=20 > I'm also interested in this. I believe an obvious solution to this is=20 > via the "name" attribute. All the ones with the same name should be=20 > gathered together. Yes. That's already mentioned in RFC7991:=20 https://tools.ietf.org/html/rfc7991#section-2.48.2 and also in the documentation for the current xml2rfc release: https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-name-attribute-4 Regards, Henrik > A problem I have with both name and type is that they are invisible in = > the human readable formats. They provide semantic information that may = > be of interest to a reader. Perhaps they could be available in html via= =20 > a popup? >=20 >> And, by the way, those type tags are conventionally lower-cased, but t= his is not made very explicit; you have to infer that from the list in Se= ction 2.48.4 of RFC 7991 or the RFC editor=E2=80=99s updated copy of that= list: >=20 >> https://www.rfc-editor.org/materials/sourcecode-types.txt >>=20 >> (Ha, this doesn=E2=80=99t even have =E2=80=9Ccddl=E2=80=9D in it; I=E2= =80=99m not sure how this is updated and whether there shouldn=E2=80=99t = really be an IANA registry for these.) >=20 > For these to be useful for any sort of automated processing I think the= y=20 > should be standardized. I agree with an IANA registry. >=20 > If we wanted to allow unstandardized usage there could be X- prefixes, = > but we have banned those many other places. >=20 > Thanks, > Paul > _______________________________________________ > rfc-interest mailing list > rfc-interest@rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-interest >=20 --f5kxD7Qw5UWFrMGIiOfPWQkOT8mtblF8B-- --MswB0rA1WHQAkcON4ulRHs4GboBBIERHb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl8XFIwACgkQTptXS4+7 FxrI7BAAzNp0uWhesHgquXQHkWMEc0btTBBW62lnem6XqniDlkh8uns7waAYGLJA fRsdFbrRE4LR3Hxz7wtJiDHebXoqkfGHNb75JGitbFjkX4tlJCs5rLdGZW+CGuyD QJuCqIMjUZE3vt7g0foJgZ81tiEAAM/DwMC2KkgxZmdiZT3DtVC8N1I70A3UvniV M7IYxW2TyZAsHNK5jSCuUn67gW6cmzAnB0T2fx6BChyY3Nz2OuYTRH7s5iUsaNtk cQEbVzHzTMHtGx0x/EqpWL+cKiqEI+V89dA/v+H1m7AAGasQoSfjkB2z0GxW9xxD k8Nma9OQWcdVl3Ji5f4Ch1zEpwXKPXhjdB2UMn1HfafSZ/tiNN809bjmmWcyFlFi pDnAslh/RTNC/tGn53nNfGuB8M++Q6gEY5snHdXX8afHJXbmQVwspkEbAnjI2C7+ UJGRgs6XgBKjPrf53Il/90lHyGN3OQf0dYuW+dQqjyB9Kl6YEGTZH++++aOpjgmZ xVJKIurG2XV6WakxwpPh6l7wway8x+bYRVnq7oCh125bHvQcbwzKkcv2zBI/8iNB 8wlGMOnMyxuFJVCUlU7p+VUuMK+Wy3aHI+bghjerVfw9jx2vH5tbV83QL6HSw/pX 4dUq2aEVdSRwOiGmy8OIQFDmIpvpuq0ZBClNgTKHwOG1lgY8AX0= =egQa -----END PGP SIGNATURE----- --MswB0rA1WHQAkcON4ulRHs4GboBBIERHb-- From nobody Sat Jul 25 10:08:00 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE623A0CEB for ; Sat, 25 Jul 2020 10:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=alum.mit.edu 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 7Kv9wb8f45wS for ; Sat, 25 Jul 2020 10:07:57 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2071.outbound.protection.outlook.com [40.107.223.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92E33A0CE7 for ; Sat, 25 Jul 2020 10:07:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dCQt4pBAvbAsdb3UyjNtk2lEu/iH4hVm+cDRa1feWveIGV3hQr+BW6k3zRvxInF92dG9fT8jUJDc/pC76lLUgNOpdgIWSFmVfEWaYNb2flPzbZvlGUw6zfFWwiTN7xDvKzMPp7mY7gqNPNvjSAl+L0pdXmgRtrx3tXI5H8O2FOxxMIrdd21YxQN1SlC0pHa/+lNVuEuCENZkknhVmIsU2E58Bdwmh0t+dZf3BVWblHYn43KHJ8lJObyXEyQS8zXoi9wK6UQ332sBW/I3R5bUZ7oj4CdY28bT37m0n2xt4IPxBGasn9sHJdciNUnnFYjrJvM5efo7qNrLL1jfH3CNVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EmNf6cxHLE0f491PG5ICqjCvwWQL+Zl9KewwGXjHndg=; b=hPzPRdhX3JFwjvXJoXY/FJcwnYD8br+LiUckZWyuPwYANLA22Wq40ec6wNKyUnyhcbYHZWNOVsl3Tik0pQS9bFISb7tnCUAys2QNsdsUXcs+xo8lJ6MDHYcnoNoU53m1bbC54BkfnBQTnVnYS1VBuboFRntA22x8pX2TTmt9fse4wXknEDT179y5qqkgY5fg/80hALtYdZlduraCkaNg3EBJON7YydVkS9NeKjyusFjjq5g5K9StlD92qGJ8VFSlZ5WngmIqBChwqhMgxdjAq3TEkxRlDJPRtSRBvdmsSniDpW4nDIR1vw3v7y8wWwWFmKEAOg9AtAQuH7NRbRgaMA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EmNf6cxHLE0f491PG5ICqjCvwWQL+Zl9KewwGXjHndg=; b=Ixx1GC+661uRYDPC9zGX4OttfuG9gM99lSSz4EZylsnLAFnYQfXBKT0ujjj3V/LM5N8U6gIjj6WXRA1oDwLA1ldtJJi7Lyim+GQTRaKTlOPQObQ/8vLlY1GEBifklCMOJ/Uw7keNUFdYCsdA5hl+sP+ESL4YxER8nvMWe3wXL5A= Received: from SN1PR12CA0065.namprd12.prod.outlook.com (2603:10b6:802:20::36) by CY4PR12MB1861.namprd12.prod.outlook.com (2603:10b6:903:11e::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21; Sat, 25 Jul 2020 17:07:50 +0000 Received: from SN1NAM02FT042.eop-nam02.prod.protection.outlook.com (2603:10b6:802:20:cafe::d8) by SN1PR12CA0065.outlook.office365.com (2603:10b6:802:20::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20 via Frontend Transport; Sat, 25 Jul 2020 17:07:50 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT042.mail.protection.outlook.com (10.152.73.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.10 via Frontend Transport; Sat, 25 Jul 2020 17:07:50 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 06PH7l1x026779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 25 Jul 2020 13:07:48 -0400 To: xml2rfc@ietf.org References: From: Paul Kyzivat Message-ID: Date: Sat, 25 Jul 2020 13:07:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 385dc0a1-1400-4325-3d05-08d830bd42f0 X-MS-TrafficTypeDiagnostic: CY4PR12MB1861: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zdL06PT1sKO1RKyVa5ssoFHM1BkdVQSnhQeA8+kmmMdZV4Ma9A1Jg95oGfPKp73IXC7DxkcPOhZxOgCAzH+ZdmhKoqpff75fkKCYK2xKicc3MruXuTt3c8ytcb7hz4pkw8d5BcP4vFo+HAfWqQKqzuE2vqqdvs9F87eiEp+a0aMkV9zm8BQH0BTeggpIIMPoFGnZgJoNmcr4qzUP1IPY07TjUg9uUvQAybut/QtvjROXMo4zeTAp7uKBJqMh6WFhPtGztfqHfXk/0FedOWOk7O+XRZT2+H6+h/5YWR9OOG0xkEc/oScSlkwrDU/JVAsZrXVEOtRLBuPZ/nhUmTW3tMZ+LGi307LsiEWs2G4uhkpFGcJnL1DGKYc+gXv3xWEogc1wB9OYfX1uLfaFuu9DDWDngXUjpbR+rIfK1v1VAXthPPANCHvWv12gvbAotzqrex2/jo675j0OlEKImKbNqrTFjhou2Ezy9xaMqjDo4NCaouuYmiuxF6R1h3IP4luh X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(39860400002)(396003)(346002)(136003)(376002)(46966005)(70586007)(70206006)(31696002)(83380400001)(82310400002)(356005)(86362001)(6916009)(53546011)(2906002)(316002)(36906005)(956004)(31686004)(8936002)(336012)(75432002)(478600001)(7596003)(786003)(186003)(47076004)(2616005)(5660300002)(8676002)(26005)(82740400003)(966005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jul 2020 17:07:50.1118 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 385dc0a1-1400-4325-3d05-08d830bd42f0 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: SN1NAM02FT042.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR12MB1861 Archived-At: Subject: Re: [xml2rfc] use of sourcecode type X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2020 17:07:59 -0000 This long discussion may be helpful and lead to some clarification that will be useful in the long term. In the meantime I still need to decide what type I should be using for *fragments* of SDP. Should I just use "sdp", or take a flyer with something like "sdp+fragment"? I'm in AUTH48, so I can't dawdle here. (In this usage the fragments aren't intended to combine into a meaningful whole - they are generally previews. There is one sourcecode element at the end that contains the complete SDP syntax.) Thanks, Paul On 7/21/20 10:36 AM, Paul Kyzivat wrote: > I have a question about specification of type in sourcecode elements: > > In RFC4566bis there are many examples that have fragments of SDP. But > they aren't compliant to SDP syntax, since it requires that many things > be present - that are intentionally omitted from these examples. > > Is it valid to tag these with type="SDP"? > > (In sip we had a similar problem. There is a mime-type message/sip, but > we sometimes also return fragments of sip in error messages. We ended up > defining a separate message/sipfrag mime-type for this.) > > Thanks, > Paul > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc From nobody Sat Jul 25 13:51:26 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161113A0AD3 for ; Sat, 25 Jul 2020 13:51:24 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etot0HUZSS91 for ; Sat, 25 Jul 2020 13:51:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA1C3A0ACE for ; Sat, 25 Jul 2020 13:51:22 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:54127 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 1jzR8b-0006qX-3K; Sat, 25 Jul 2020 13:51:21 -0700 To: Paul Kyzivat , xml2rfc@ietf.org References:

From: Henrik Levkowetz Message-ID: Date: Sat, 25 Jul 2020 22:51: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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sJWVn8BDj5O4UnalIw8Je4m4NJ719DOTB" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, pkyzivat@alum.mit.edu 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] use of sourcecode type X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2020 20:51:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sJWVn8BDj5O4UnalIw8Je4m4NJ719DOTB Content-Type: multipart/mixed; boundary="VFDfAW9jlQ9xCnX1fcBWN4Lb7Qrj2BJd2"; protected-headers="v1" From: Henrik Levkowetz To: Paul Kyzivat , xml2rfc@ietf.org Message-ID: Subject: Re: [xml2rfc] use of sourcecode type References:

In-Reply-To: --VFDfAW9jlQ9xCnX1fcBWN4Lb7Qrj2BJd2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Paul, On 2020-07-25 19:07, Paul Kyzivat wrote: > This long discussion may be helpful and lead to some clarification that= =20 > will be useful in the long term. In the meantime I still need to decide= =20 > what type I should be using for *fragments* of SDP. Should I just use=20 > "sdp", or take a flyer with something like "sdp+fragment"? I'm in=20 > AUTH48, so I can't dawdle here. Given the documented intention that fragments with the same name=3D"$file= name" attribute should be gathered together, I'd go with "sdp" if they would for a complete whole if gathered together as one, and your suggested "sdp+fragment" otherwise. I don't see any obvious improvement over that.= > (In this usage the fragments aren't intended to combine into a=20 > meaningful whole - they are generally previews. There is one sourcecode= =20 > element at the end that contains the complete SDP syntax.) Right. So "sdp+fragment" then. Best regards, Henrik >=20 > Thanks, > Paul >=20 > On 7/21/20 10:36 AM, Paul Kyzivat wrote: >> I have a question about specification of type in sourcecode elements: >>=20 >> In RFC4566bis there are many examples that have fragments of SDP. But = >> they aren't compliant to SDP syntax, since it requires that many thing= s=20 >> be present - that are intentionally omitted from these examples. >>=20 >> Is it valid to tag these with type=3D"SDP"? >>=20 >> (In sip we had a similar problem. There is a mime-type message/sip, bu= t=20 >> we sometimes also return fragments of sip in error messages. We ended = up=20 >> defining a separate message/sipfrag mime-type for this.) >>=20 >> Thanks, >> Paul >>=20 >> _______________________________________________ >> xml2rfc mailing list >> xml2rfc@ietf.org >> https://www.ietf.org/mailman/listinfo/xml2rfc >=20 > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc >=20 --VFDfAW9jlQ9xCnX1fcBWN4Lb7Qrj2BJd2-- --sJWVn8BDj5O4UnalIw8Je4m4NJ719DOTB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl8cm0EACgkQTptXS4+7 FxoClA//aX1zqbOIASBpO1zLSY+pjd+bB+ai0vH2WyLTDLFT9vBU0XJEzggBijld KVeQ0RgDihTD1T1pDniDeRLrTCwT8rJjdEmc+w6CfjYpBxh246n57dhufETFGGjl L58dCAS/2kcWSX2KmfOi4NCwA9sRwrVwQcnvwzlLBwesuxlGl3SQ+g/x/p4X4q6o jYwd351Q+hMq7X6/TTv5LT1I8UbmRfx/5Ero3+Nhuda4MNxEkMwaK5ZZF73JyrBt RV8p0Vy8yp2DBX3DflnqCVvd8/IFKo1T1g8f8V6jDBkmMQU9uCtYR4u6gAwS+SAk ght2rrfyq/EyYoTZjl8Ds8KLrY5pUpyXV412C01YgCphbCbnjkfExR1GBjNIKpUS svHJSus+J/QtRz6OhVNxd7g6ky25go/brR5ugLAoQBntZr8SPzNoNVv//kkVaOEH DyzYjrNk0lh0ZOdGtRmguRyYpKtrjoeaBd1vS6bwGRFXnhq1jiRtvjoEtflT+Gqu 1TzSZXWoQ9FRfheRHk6Q7OGr2MiS7o2OkuK3zF1FkqYBv+rJyKooX8QSUej/xTJI MrkhDsPPWnIEL/9T0XNkXANjjK2rGV2ERfPhjzdcLJlbCkECNnUfTKLdn4mmLlxx HqHallEBZhoZkLYJH5PHKwmjQT5XET4nsS3Cct9xRf4ncI7COTs= =Bk9e -----END PGP SIGNATURE----- --sJWVn8BDj5O4UnalIw8Je4m4NJ719DOTB-- From nobody Sat Jul 25 15:24:36 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E173A0B4A for ; Sat, 25 Jul 2020 15:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy8T_0ONt68E for ; Sat, 25 Jul 2020 15:24:32 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B9543A0B47 for ; Sat, 25 Jul 2020 15:24:31 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BDgbd0wRlzyVQ; Sun, 26 Jul 2020 00:24:29 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 $3608.120.23.2.1$) From: Carsten Bormann In-Reply-To: Date: Sun, 26 Jul 2020 00:24:28 +0200 Cc: xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 617408668.492231-f7da65bf50134aa91593e2db49b4a9d2 Content-Transfer-Encoding: quoted-printable Message-Id: References:

To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [xml2rfc] use of sourcecode type X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2020 22:24:35 -0000 On 2020-07-25, at 19:07, Paul Kyzivat wrote: >=20 > sdp+fragment This makes me cringe slightly because it looks like a structured syntax = suffix (RFC 6839), but it isn=E2=80=99t. (Structured syntax suffixes add a superclass to a name, so senml+cbor is = a form of senml but also is CBOR. Fragment doesn=E2=80=99t strike me as = a superclass here=E2=80=A6) I=E2=80=99d prefer something unloaded like =E2=80=9Csdp,fragment=E2=80=9D = (or =E2=80=9Csdp, fragment=E2=80=9D =E2=80=94 this is free text after = all, but that may be too radical). Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Jul 25 20:35:37 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549DE3A0A26 for ; Sat, 25 Jul 2020 20:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 PPaBWS2FCqdO for ; Sat, 25 Jul 2020 20:35:33 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2062.outbound.protection.outlook.com [40.107.92.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547443A0A31 for ; Sat, 25 Jul 2020 20:35:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PcL/IAeZJr3+HWpQ7cFiup2rqsV+kJpDRmymWKFq60CP4aCalaCNjnkuQYcD/fCeFnj3FFxm+EWxzQaDYPLnLKkulBqQL5E0BshyEdy13mTj5JGQCXXcQCJPYYH1mzmPNOQ82pn0bDeIgvGIM7l8USqyKyF/x8t+wErC8aiNlv01rtXvN5zXGLf+xp6I939jinK9+TihgdIPZ9UU+5BAmRSysGaxL+jvGPRXkzA7fd2EfvB14XOT0B61nh5wKYYQBDM4pPC+jA0tLEwb+CyuiiTHzGWeKnHToJhr+cK9XvgpRNHB25Y+3OtZIonuaAHXoBrwnCmITM+eAZhwIDmQgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Wk5yFUTTbPM8FvJTdA+3GKYiQ4EtlQp/m3I2JYCJme0=; b=fwjMV/nXNwsL9wm2UBIUClV/uGTTleSeHva22c1Qm+PClejoANoQiRmm/6fyke+QqMZWNPfnzw87C9op+d2h03z5+jr1A1H8GTZn3x6xz8nwfikZhmgYCLHx6TIgN57rmD1OT1oyEelHVq44NYgKZnf/tLYwjtcVCcB+LAJufBI0XqUeuGB0BOZ0UbN07dQxk1Bv7u/RshReIXZ5K2pFE6COs7Wbb68OoSLnIO0NZoqPbCwJWSJXpiTqV5jyLMXJAfeJoUoW8gR3U4B9mGScrXEslWDDTM6AE4rYQhrYAJOXkkYYBIral5DbBLBbzYNiLoICN7DUR8ygQFoay0/AJg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=tzi.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Wk5yFUTTbPM8FvJTdA+3GKYiQ4EtlQp/m3I2JYCJme0=; b=JzkrS1sfsJjnQ7O6LiQvJh57Hnz4h+XNUqYWA+74HvmBw/MeLqz2NUvrEBea7TNMtulbtytWWk7P8CTpkppdf+t+7zthII5dGkJ6lAqY0n+xUXlKg2hh5+pL6aWNgo+/7w1PZLKTgZvD/qtBpGj0hVsVnWFSp1tl7YQeQmNsawM= Received: from MN2PR12CA0035.namprd12.prod.outlook.com (2603:10b6:208:a8::48) by MW2PR12MB2569.namprd12.prod.outlook.com (2603:10b6:907:11::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Sun, 26 Jul 2020 03:35:31 +0000 Received: from BL2NAM02FT056.eop-nam02.prod.protection.outlook.com (2603:10b6:208:a8:cafe::b1) by MN2PR12CA0035.outlook.office365.com (2603:10b6:208:a8::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.30 via Frontend Transport; Sun, 26 Jul 2020 03:35:31 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT056.mail.protection.outlook.com (10.152.77.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.10 via Frontend Transport; Sun, 26 Jul 2020 03:35:30 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 06Q3ZSop002930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 25 Jul 2020 23:35:29 -0400 To: Carsten Bormann Cc: xml2rfc@ietf.org References:

From: Paul Kyzivat Message-ID: <620319f3-a85f-64d6-0e9e-769b24da49ff@alum.mit.edu> Date: Sat, 25 Jul 2020 23:35:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 87625af4-3c1d-4330-3757-08d83114f23e X-MS-TrafficTypeDiagnostic: MW2PR12MB2569: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: qvDT+tVsAJy/Msm8voQa8cXMlXdbWH5doH356OJhO1SXB+55hTrpevey7ez4gK0LhYjm263RZWdlH92aS7+0xKk4AQ/esRXTmTsXjPNp99D7a/ud7YRBpf+Cw3/tVvSOB9X2eRrxUc59lRlVtoa9WAUv0T6R5VnM6htOI6J9F+q6ScTLP9S0PslwLq/humxXuTMq5EMXVumBZXkmTkdWgY4SR95vf9bJ01qZ5o5dHFE4nA6zjY7+J339fJgnTj+f+SWQsJO9fYm5I6t6FmJAWDwlYKGeA7Y77Bm2qaV1lnLtTovH2HYN29uXL6bAOpSMCIU9wBEBJEIOHUD6wqTv0MffgjZ+zwwUooiJh1SNG6wsMV8Gjx+5dIv6MUKZsTX0VM8x4oJVUj7RjETLj/DGvPA5AhobZeKeMuRNUYSs5EHTy89T0S1BXVpHAOvOsaPS X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(346002)(376002)(396003)(136003)(39860400002)(46966005)(4326008)(336012)(53546011)(8936002)(956004)(2616005)(186003)(6916009)(8676002)(26005)(31686004)(86362001)(31696002)(75432002)(2906002)(786003)(316002)(82310400002)(5660300002)(36906005)(478600001)(83380400001)(4744005)(356005)(70586007)(7596003)(47076004)(70206006)(82740400003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jul 2020 03:35:30.4916 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 87625af4-3c1d-4330-3757-08d83114f23e X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT056.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR12MB2569 Archived-At: Subject: Re: [xml2rfc] use of sourcecode type X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 03:35:36 -0000 On 7/25/20 6:24 PM, Carsten Bormann wrote: > On 2020-07-25, at 19:07, Paul Kyzivat wrote: >> >> sdp+fragment > > This makes me cringe slightly because it looks like a structured syntax suffix (RFC 6839), but it isn’t. > > (Structured syntax suffixes add a superclass to a name, so senml+cbor is a form of senml but also is CBOR. Fragment doesn’t strike me as a superclass here…) > > I’d prefer something unloaded like “sdp,fragment” (or “sdp, fragment” — this is free text after all, but that may be too radical). This is why I'm asking. Perhaps "sdp;fragment", borrowing from mime parameters The point is that it is *not* sdp, but it is *related* to (derived from) sdp. I could use "sdpfrag", aking it clear that it is a different type. (Following the precedent of message/sipfrag mime type.) The advantage of "+fragment" or ";fragment" would be that the same modifier might be used with other types. It could be defined once. Thanks, Paul From nobody Sat Jul 25 20:47:44 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC2B3A0A53 for ; Sat, 25 Jul 2020 20:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eK7mMHKDKgM for ; Sat, 25 Jul 2020 20:47:40 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0709B3A0A4A for ; Sat, 25 Jul 2020 20:47:39 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BDpmT3hZPzyTh; Sun, 26 Jul 2020 05:47:37 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 $3608.120.23.2.1$) From: Carsten Bormann In-Reply-To: <620319f3-a85f-64d6-0e9e-769b24da49ff@alum.mit.edu> Date: Sun, 26 Jul 2020 05:47:36 +0200 Cc: xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 617428056.853351-c51ba04a7fd657b3e8bce5d12b185fda Content-Transfer-Encoding: quoted-printable Message-Id: <19222579-56F7-4EDA-88DE-C30DE711903E@tzi.org> References:

<620319f3-a85f-64d6-0e9e-769b24da49ff@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [xml2rfc] use of sourcecode type X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 03:47:43 -0000 On 2020-07-26, at 05:35, Paul Kyzivat wrote: >=20 > sdp;fragment Looks good to me. (Note that these are not MIME media types, so we are not preempting = media type parameters, which would be bad.) Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Jul 25 20:48:01 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204F33A0A55 for ; Sat, 25 Jul 2020 20:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 mpAaM2G8cMpc for ; Sat, 25 Jul 2020 20:47:57 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2051.outbound.protection.outlook.com [40.107.220.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75BF63A0A53 for ; Sat, 25 Jul 2020 20:47:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lB06fTV/itOAX5jdvDUq3qgq8+gAfmFhfnXDH+WxH7z15zmfXuCIFZZjX9wJTx4fuBdHpv69/VdZTCYnksK/PYrrbQ2l/ZEXyS6tuWPt3oyQ8Ygd6D+YyFmzAyf+kr+vB0ok+u9K/6ix2vJqnQ2ALjSVq6dTvC8ZKxddfykgbnAw5WxLA/pNo7q9mZyqatatPrsnR9e37HD3XZeu0iLgzWjTSkkJ7ni4p/KR9LmF1dreWK0PHjA03ICYeE6YVkZvgkDd58sC+EWFf3XcP2UqiSPjmRcDY4TaAzXmuKdxRovhvTwtr6X9In7ioMqGhK6XfHjKySnbggxCH9XVrEjr4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fPgY2JfgDNyivCZwFsVfG3QBYyfFcsVjycLmBdn9MPo=; b=VVtYeMyp0gEglJhMA65DYmN4OW/KUeexMaq+PqZ2ZD6J7dHj4LnLVgN32Elj3xifVs/2LMI8DgsjEqt059GDhrasw5Ufm1iuslUDuXfD9qY4nonADO+LI62rK4ttyD9Lcq7X91C9/1ryK4DfeaNsv8M6KliVpJ/Gp1QX1UlAIRVmN3su0Lh76Tr9+S8xyeNum1Cder6nFN9bWouEmfPHHMb/CBSg3Cn22Wva7tEIdJpvrB2m1DUUe6jWK3ZnnWGqyz41ZGlWdmhsk0ybZHqtl4FGll/pvGWwIxVJtQFnbe64OZzrt4D9vjsKViBpB6WeJU/rNIZJW2qv13ahlXBxbw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fPgY2JfgDNyivCZwFsVfG3QBYyfFcsVjycLmBdn9MPo=; b=HqdeTvnzMV4G8BALR9ea9H1jDbi8mBGcV3To+NKAvaEtw+EtgSzUw37oCqjqvHE+0lGY6ltgKBawg9i97uKa8WClTqO6YUhjr+qjRXcK6bTCvwTJJtuU4sAlgNQs4qOPU026YTSKtsQnFBMBoNuIx8Fm/YFx7ra2guPLodBwpOY= Received: from MN2PR05CA0063.namprd05.prod.outlook.com (2603:10b6:208:236::32) by CY4PR12MB1160.namprd12.prod.outlook.com (2603:10b6:903:38::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Sun, 26 Jul 2020 03:47:56 +0000 Received: from BL2NAM02FT034.eop-nam02.prod.protection.outlook.com (2603:10b6:208:236:cafe::14) by MN2PR05CA0063.outlook.office365.com (2603:10b6:208:236::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.10 via Frontend Transport; Sun, 26 Jul 2020 03:47:56 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT034.mail.protection.outlook.com (10.152.77.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.10 via Frontend Transport; Sun, 26 Jul 2020 03:47:55 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 06Q3lrkW003688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 25 Jul 2020 23:47:55 -0400 To: xml2rfc@ietf.org References: From: Paul Kyzivat Message-ID: <5f6ffc13-eaa9-c677-4c62-df55dc15e515@alum.mit.edu> Date: Sat, 25 Jul 2020 23:47:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c43a3132-8688-4bd1-0206-08d83116ae71 X-MS-TrafficTypeDiagnostic: CY4PR12MB1160: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mN7zjh7fqIaap685raJH4S8buZ6FLmmGM2S5i1ebM/cAaHwPVdhX2mdezabbu8ln04QFdLAQO8sI9IKaNdNyX16YUZmGkRVb3yvDyvADNBmPv47Fv++DCqQMY5jF39gmvXKrbxSRGLPRxhRrbOiHebaaj5xyL4hSaV6HBz38fLJUbodOJqMgL4+AQf7Cc2wPIU4UptWirBCCRseQPED/l380GgNYFuZFvZWQSuepJ3kpRjkgNbusTPki0BJ1DQSoBOMLuU1cawPgOzJ8JWtEX4np9LXs/XOeeWtw7gZBuTJLcbfeLJOQhuHl2WMSJraHAhWRzodM02KXtxduJz3E7+WLoRhbZfyQ/kP9AtEjivucZ6R4sT9yWcwvO8Np4sFo4EsKsJK/FZPku43iliWJE8V+krKXQ9pzziemn++/NwJMDBWmwfq+GJVn1/RCaol7 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(346002)(376002)(39860400002)(396003)(136003)(46966005)(70586007)(82740400003)(70206006)(36906005)(786003)(82310400002)(316002)(75432002)(8936002)(356005)(47076004)(7596003)(186003)(5660300002)(8676002)(31686004)(336012)(956004)(2906002)(4744005)(26005)(6916009)(86362001)(2616005)(478600001)(31696002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jul 2020 03:47:55.8024 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c43a3132-8688-4bd1-0206-08d83116ae71 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT034.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR12MB1160 Archived-At: Subject: Re: [xml2rfc] use of sourcecode "name" attribute X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 03:47:59 -0000 In parallel with my query on the type element, I also have a question on use of the name attribute: It is described in rfc7991 as a filename. But there isn't much discussion of what syntax is permitted, or conventions. I gather that it is intended to be flexible for different environments. So for purposes of this discussion lets restrict the scope to use in IETF drafts and RFCs. Is it appropriate to use file extensions? IOW, is it a good idea to use an extension to identify the type of the content? (E.g., "syntax.abnf" and "example1.sdp".) What about use of "/" to introduce directory structure? I'm thinking of how this might relate to tooling and storage. It would be nice if it was possible to have URL paths that retrieve a particular named element of an RFC or draft. Thanks, Paul From nobody Sat Jul 25 21:05:45 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013163A0A8D for ; Sat, 25 Jul 2020 21:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-oIqtOovwQB for ; Sat, 25 Jul 2020 21:05:42 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4E53A0A88 for ; Sat, 25 Jul 2020 21:05:41 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BDq9C6YLVzytR; Sun, 26 Jul 2020 06:05:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 $3608.120.23.2.1$) From: Carsten Bormann In-Reply-To: <5f6ffc13-eaa9-c677-4c62-df55dc15e515@alum.mit.edu> Date: Sun, 26 Jul 2020 06:05:35 +0200 Cc: xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 617429135.351506-5f94ac36dc57d0802d3e154c0fb77531 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5f6ffc13-eaa9-c677-4c62-df55dc15e515@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [xml2rfc] use of sourcecode "name" attribute X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 04:05:45 -0000 > On 2020-07-26, at 05:47, Paul Kyzivat wrote: >=20 > In parallel with my query on the type element, I also have a question = on use of the name attribute: >=20 > It is described in rfc7991 as a filename. But there isn't much = discussion of what syntax is permitted, or conventions. >=20 > I gather that it is intended to be flexible for different = environments. So for purposes of this discussion lets restrict the scope = to use in IETF drafts and RFCs. >=20 > Is it appropriate to use file extensions? IOW, is it a good idea to = use an extension to identify the type of the content? (E.g., = "syntax.abnf" and "example1.sdp".) As long as it isn=E2=80=99t =E2=80=9Cmalware.php=E2=80=9D :-) There is some redundancy with the type here, type=3D=E2=80=9Csdp=E2=80=9D = name=3D=E2=80=9Csyntax.abnf=E2=80=9D sounds wrong, but then you don=E2=80=99= t have to make this mistake. > What about use of "/" to introduce directory structure? Yes, but: =E2=80=94 no . or .. - a leading / would be interpreted as relative to the RFC, not relative = to the local file system (i.e., it would be ignored, or signify = something else than overwriting the local system). > I'm thinking of how this might relate to tooling and storage. It would = be nice if it was possible to have URL paths that retrieve a particular = named element of an RFC or draft. These look more like fragment identifiers to me. (There is no problem with fragment identifiers that collect content from = different places in the document. There is also no problem with = shipping a fragment identifier to a server for server-side fragment = extraction as part of an API.) Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jul 26 00:16:55 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8650A3A0BD3 for ; Sun, 26 Jul 2020 00:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 boFMhkOMZHzi for ; Sun, 26 Jul 2020 00:16:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605E03A0BD1 for ; Sun, 26 Jul 2020 00:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1595747808; bh=OHkzlKsDUTQ9ZFI39YtyER08LYsKTPKH5A4Y1bkfnsM=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=G9hAxPOVLXgRSmygNGvChXx8n6McoaUpvCbub36n5UkwwBr+jc+KUsWuCyP1H/wnv SCzKkDriy7d3TEklpAYF57dmXIWoRYp2TsCK3PRoQeDKfh2zOfrUlYfyHyAsiw1/aw ksW9K7Vq3SUC3tMTpufbmy+avUfyfg6ZMe2M2kps= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.182] ([84.171.145.184]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MIx3I-1kFbaM0wck-00KQCc for ; Sun, 26 Jul 2020 09:16:48 +0200 To: xml2rfc@ietf.org References:

From: Julian Reschke Message-ID: <234e7cfc-d4b1-a748-6092-5bb5a46a004f@gmx.de> Date: Sun, 26 Jul 2020 09:16:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:FplWoSdXeYYAL6hFpL9C9cgBl526cYFKpb8IprSYNoPkVg5UTUA UDGbXtiZBUa8En8fFoSCM1Ic5HeQhEiRxOW0NOe/5FOQqMPPSI2hMeu6mirkDsWd89+ZzSx iV/nOUXQrbW72QWnVbxS5b4agCdx8QzWXecLpLTxoeBuoLZ1C43Gn5BsFjKmTx5ACByyGnt hJ58HLkOtTsSuFa8yU06A== X-UI-Out-Filterresults: notjunk:1;V03:K0:OTGndxiWIyo=:/NG/F2SKHqWLB13/ZK4XTE e43h5n7D43tXh+2ZjvSxGcpl/oLp2cA2Ye3q/qAJ1fDfY///V3EvctdZV+Fg/80DrryPomXiZ qgDtc/7c5JjkpQ+Ge2hQKmnhRjDX3EADrscMLK87w++MOQpWU9I72yNMy3dmxZ6/3fsYL/NJj R6BWv3mjzWzeQbzFG9E5bCMUc3b1LyNbYD1sUuyOKkfiIwI10TcltwIgKEGdrO0CfyzlHNZua IF4IndJQO+TgxayRaNqBB/UofGAq7c5ddsTIfCocqIHieQrwsCTN+h3p/SpoJ09Qi09yJDRKd P5pIb+KQUHwrildJOE0i/7IW91j8jcBtKOZ9n5TMQhlc0DZHWshHjXMEBcthKb04U2iFuYIXO UPbOdYFO2fe/pM88RGmjrKmvJ6TAM8gaxNq8EzDKRD7Kzb5Cot87a8x82zYoRF2UllqLLDbGt o+9JoHtMTCDcywLC69ATlb6uCHR5glB+9ZdedrFZbkwGCDslLnViOb/SmGZU6xUljMQ9TYTyT 2Ya4o4VI7O0jNEP2hU1B/CKvcU79Y2ujL+h7sXxeFHCgjY+aspKF+akPLwFw2ZGfqDIZPmY1U mtIKl28rinGkpAwP4mWBIlLQ6PQNyFVKa9XICPTk9+RcKbd4/2+9rybBaqR7cFAQR3LMl2AwE ZblVIju6LrPcF5VfeHmlPsbV7Zj2h79i0zfcIuNgWoyJbhTRdjWrqGiHia1W+dmfSTHopSyLy ew1BjsXKV97CC+ysvs+Lao3J4rmezrgYk5T/hIcj31i/9vI+YUbx8jpfIXnN8E6aVs9/UbB28 P9KxDqu9Xo+l01Ef84RZuq9b3Oppryo3NhKYNDrUWU5hicxH1c0gZIbXMG0QQlHqho9i28cwH 557LPQrM7LlP8Y5FWmvuwvvReMtJPhuUyc8EAj0dKu8fPZDPWewY0ywCtewICQkD43lZnZrYj tUHvLcjRzVuJwRZSaClYd90MSv8OHlvCOHT2vGwuEe4zx16fx4tmDs+OmKUiOsAlW4X8EbHJS Y2ZnNzH22VItAmnTz/whexPN4H3MPqe8OS4H+uR947Rv0g7cqixRXZ0SBY8aEOLc9rrGUiriF 46IgKHt7hYtcIBaRa/Frc8kWKlMGsUy4OpW0aLd7GL7mNIxlWO7pSGSiFjZbahXMw/lTPxckI AqcNracmbTQ6oC3ouVKoZ1koKmqjrOmc1F2+xVn8B0CxHXkxaMkqL0GXhaf/itl1JMj2XpViw S0XG8SoeepCfCrdoi52STRYNALYjR7cdUuI0/ZQ== Archived-At: Subject: Re: [xml2rfc] use of sourcecode type X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 07:16:54 -0000 Am 25.07.2020 um 19:07 schrieb Paul Kyzivat: > This long discussion may be helpful and lead to some clarification that > will be useful in the long term. In the meantime I still need to decide > what type I should be using for *fragments* of SDP. Should I just use > "sdp", or take a flyer with something like "sdp+fragment"? I'm in > AUTH48, so I can't dawdle here. > > (In this usage the fragments aren't intended to combine into a > meaningful whole - they are generally previews. There is one sourcecode > element at the end that contains the complete SDP syntax.) > > =C2=A0=C2=A0=C2=A0=C2=A0Thanks, > =C2=A0=C2=A0=C2=A0=C2=A0Paul In any case, this should be tracked at . Best regards, Julian From nobody Sun Jul 26 04:23:59 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA363A0DAE for ; Sun, 26 Jul 2020 04:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sz38qJA7DKoO for ; Sun, 26 Jul 2020 04:23:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018D13A0DAD for ; Sun, 26 Jul 2020 04:23:55 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:50553 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 1jzel1-0005or-4L; Sun, 26 Jul 2020 04:23:55 -0700 To: Carsten Bormann , Paul Kyzivat References:

Cc: xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: <3c0257f0-af88-08d1-18a2-26d2ace3968d@levkowetz.com> Date: Sun, 26 Jul 2020 13:23:41 +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="QNMtheKlrj5bQIgi8KEAAKCfEJReVMgei" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, pkyzivat@alum.mit.edu, cabo@tzi.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] use of sourcecode type X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 11:23:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QNMtheKlrj5bQIgi8KEAAKCfEJReVMgei Content-Type: multipart/mixed; boundary="bn6hKU2EnE7x9rOtOvabxNE9Kl3hqFJJM"; protected-headers="v1" From: Henrik Levkowetz To: Carsten Bormann , Paul Kyzivat Cc: xml2rfc@ietf.org Message-ID: <3c0257f0-af88-08d1-18a2-26d2ace3968d@levkowetz.com> Subject: Re: [xml2rfc] use of sourcecode type References:

In-Reply-To: --bn6hKU2EnE7x9rOtOvabxNE9Kl3hqFJJM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2020-07-26 00:24, Carsten Bormann wrote: > On 2020-07-25, at 19:07, Paul Kyzivat wrote: >>=20 >> sdp+fragment >=20 > This makes me cringe slightly because it looks like a structured > syntax suffix (RFC 6839), but it isn=E2=80=99t. I can see that, yes > (Structured syntax suffixes add a superclass to a name, so senml+cbor > is a form of senml but also is CBOR. Fragment doesn=E2=80=99t strike m= e as a > superclass here=E2=80=A6) >=20 > I=E2=80=99d prefer something unloaded like =E2=80=9Csdp,fragment=E2=80=9D= (or =E2=80=9Csdp, fragment=E2=80=9D > =E2=80=94 this is free text after all, but that may be too radical). Since fragment is a qualifier a comma-separated sequence also could be misconstrued -- what about "sdp(fragment)" ? Henrik --bn6hKU2EnE7x9rOtOvabxNE9Kl3hqFJJM-- --QNMtheKlrj5bQIgi8KEAAKCfEJReVMgei Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl8dZ70ACgkQTptXS4+7 Fxq9+w//Xk5BW4qCWPMTL0floFRXAGYGLe3zFRpTdZXIUZPG1WzLQmal6+qh+M7h dm0vBs/z1YGy46KLx3F+4yu1PQm0N9vDVTJi6x220s+WoeRl8aCJHRWA0nt5iVho hK32vFkqMcX0Gik+wgLlOnnX94AbGB7gAsLMjVvC8EcvzDAzJhmC9IsK6AeJ9Urj /3ezyPHMcbKNkYSEkmd4FCs6Do+i7aqHWjh42W19MHjSFgwVQCPTTlcd6VbXLpR3 B20sa/8KKfVELiXxE6f/p/TAa7OjdOp04f/1Kh/TfOnLwv2Pp0175v46eG4ckhjR w7S+qTIrrKyBLAmJBMiwuHauDBVG1yyRMSQNRwDG+FRuPor+4KnDxFde4KA44gbo PJWTUoBvLzt1xnRERVIiqezW/QkkpoWnACPW/ho8ormwCWBZGhO3ZEvGT0TZo2xp UAvDMjmhacT6r3gRDetn2WTtvdXMJfqpwcjFudbg1aHBfDaGBG2ZG9c4QE+Toz9u 9VGqayEK0AjqPoHkIcAjL5EOOLC8JN+AvYh3fAcuXE8DZt8UAC95mYaZSqXMrDzR XsHf9UnTFcG4kYbhBJcC0gafKS4KjlItQjlw+MNsPYwQCflV8ALRNh5CNGqCop8D KMd1Bj7uBcYQcyiQW3zwG6Lx9Xg9e+ClP4qObn7PyhvLLPv9NQA= =p4kZ -----END PGP SIGNATURE----- --QNMtheKlrj5bQIgi8KEAAKCfEJReVMgei-- From nobody Sun Jul 26 04:28:36 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E243A0DB8 for ; Sun, 26 Jul 2020 04:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYpTNNNRGQNF for ; Sun, 26 Jul 2020 04:28:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 870643A0DB7 for ; Sun, 26 Jul 2020 04:28:33 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:50617 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 1jzepU-000665-DQ; Sun, 26 Jul 2020 04:28:32 -0700 To: Carsten Bormann , Paul Kyzivat References:

<620319f3-a85f-64d6-0e9e-769b24da49ff@alum.mit.edu> <19222579-56F7-4EDA-88DE-C30DE711903E@tzi.org> Cc: xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: <424cd39f-df99-9bda-c9da-18437be7c939@levkowetz.com> Date: Sun, 26 Jul 2020 13:28:25 +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: <19222579-56F7-4EDA-88DE-C30DE711903E@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qVkBheOt9B1DGH4d7koealORTueJHuo5f" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, pkyzivat@alum.mit.edu, cabo@tzi.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] use of sourcecode type X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 11:28:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qVkBheOt9B1DGH4d7koealORTueJHuo5f Content-Type: multipart/mixed; boundary="QsKl0T01fIfxsK85a1UosOnRexBdLeVBT"; protected-headers="v1" From: Henrik Levkowetz To: Carsten Bormann , Paul Kyzivat Cc: xml2rfc@ietf.org Message-ID: <424cd39f-df99-9bda-c9da-18437be7c939@levkowetz.com> Subject: Re: [xml2rfc] use of sourcecode type References:

<620319f3-a85f-64d6-0e9e-769b24da49ff@alum.mit.edu> <19222579-56F7-4EDA-88DE-C30DE711903E@tzi.org> In-Reply-To: <19222579-56F7-4EDA-88DE-C30DE711903E@tzi.org> --QsKl0T01fIfxsK85a1UosOnRexBdLeVBT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2020-07-26 05:47, Carsten Bormann wrote: > On 2020-07-26, at 05:35, Paul Kyzivat wrote: >>=20 >> sdp;fragment >=20 > Looks good to me. Ack; works for me Henrik --QsKl0T01fIfxsK85a1UosOnRexBdLeVBT-- --qVkBheOt9B1DGH4d7koealORTueJHuo5f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl8daNkACgkQTptXS4+7 Fxoq4A//TkJLdUw4+qIUbjIToOYd/xOCwkAModiA4zC4o1ufm1Byx4iM2EELfWSu YmejhIZCnf/OCayMDCvbeU/1Dr/SHlaXM6RW3zNXRCunMo5QWms9sJ6Hw/14kVxb uFUMJwMFj5Io+4cipKfK18lmxKGrAJiXkpVmztcjrRKz0G3P8ap8svIHQNLJvZZo IBT94GLweaSRKDLEi6baJz6hMmkQsrKQ3t6m3/fLsdOEupOb0wkh+WUtvzN/83U+ 1M/Fqv1mblzMBmmvsGj8TyPKU4XoGPJf6eD7I8KuBlviEKtAyg7oq3yTexenQKEe nKyNPuIWjwfF7alGxUXid1Z3O8G7rBl6goeZ9zP1CkpnkekjvYvz5hSr5HjYwgyS gNNe0de+zM9xtNe+GhhY7eNXEpewBEhD51ASH6gXP875TITbjfxEciX+22c9ud7w JTdYFpklnhDQ4oOQZA+v5MkugC4rqevTgbKjCk7UfuTGBTWJ/MLnL/PYFv4z91WT D9VNRKU1UQFpTQU2GZ6skwZ9KMDBkXeykpLLOQRgVmBhHI1yiI8/jCTlTIBByTr4 2a7dF6BcEXMsmcSXl73FwAd8iL124OZMEi4uI7ZZxiW25QQvoS81NqKv7k1g8wmE dT9CJtBotYvvOENRPZVtQdCF+/Ex7+W+so6eWUq5HR7ndQ2Y/Sg= =UEtw -----END PGP SIGNATURE----- --qVkBheOt9B1DGH4d7koealORTueJHuo5f-- From nobody Sun Jul 26 11:49:13 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C711F3A13B5 for ; Sun, 26 Jul 2020 11:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 TjE2zAENau25 for ; Sun, 26 Jul 2020 11:49:08 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2047.outbound.protection.outlook.com [40.107.92.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892DB3A13B3 for ; Sun, 26 Jul 2020 11:49:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HKU8Ak6IaR56Ik6LDBYPuxq7ccW4xMwtKLQYxO6n/4s/7cvL9mxF2DXum0Jp9n7aAkCImg27lDlayi/ENPkcLWlYqBhS9lOp+C3/Ntevzq/Uplozd6yLGDPaTpm1NRo2akxVixAXGCr7hev/sNlXlbZA4BuK3FBzwHjHE+PkwrTiKiwzatuNvjT0ptDtYdJUrDGK7V8iWJ2vHhLrVzis1BFas5jvHPYjP0k6p1haNhsjMbiCaoAC/zxiSJg5oiY/3SXCnbDbEpMfHXo+2S/gfVh/mLp3CzruL8Nv2GI+8q3gOUjf9yD3X6kVZJdkoXBWf+nwZTM8qh+aI2Fu34t9OA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nay4wOEjDFO6St7AOWVBupM1iWUVI8LlDJEsVG66SpQ=; b=Y3+jomYJ8P4U/Vw4d9F4sqd5y8rMLQz/iYpCfbY14QSwu6qqp1mulNOO6PLv2bwwz2zIKBUi6YSOx9hmjTkdPErl7mLDOhOZwzRieC3GQkuvVRGbk37fIZ+ia69Xb0F0u0oOORON3qTQzABt1GrR51jaXltUwvWKcPZL8HzGXwEA4mp0A5I3MiJs+EiDYOWzXcUCXKY1QanNCZ463pfOvY7wds+46P9iigSfn4ec9NP7/FdS3jmuPRPaF4B5mEt00RvU9A75Vm/obpUM2+rjkXQVLaOqLKPHtAWMlMLMo23334VU8ky2YJEzv4uUMQGwYRxGlRuVUb30xET8qje9xw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=tzi.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nay4wOEjDFO6St7AOWVBupM1iWUVI8LlDJEsVG66SpQ=; b=PVvO+MB857Kj7vaBg9FBtZuMTIkXI8x5s4RASbKjF0GJ9DzK2dFJ0sTexzVR7Rr+uVhbH01We9dcReud+++TLDlI3OPt4ZfPHCAeG8g/RJWS/jrdZBpd85OwB6fu9FJ3JxujU1I96CsnC42npSI8OY5sTVG2cQZJ+XTgp3nNVgA= Received: from BL0PR03CA0035.namprd03.prod.outlook.com (2603:10b6:208:2d::48) by MN2PR12MB3952.namprd12.prod.outlook.com (2603:10b6:208:164::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Sun, 26 Jul 2020 18:49:06 +0000 Received: from BL2NAM02FT007.eop-nam02.prod.protection.outlook.com (2603:10b6:208:2d:cafe::23) by BL0PR03CA0035.outlook.office365.com (2603:10b6:208:2d::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24 via Frontend Transport; Sun, 26 Jul 2020 18:49:06 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT007.mail.protection.outlook.com (10.152.77.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.10 via Frontend Transport; Sun, 26 Jul 2020 18:49:06 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 06QIn3ho024315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Jul 2020 14:49:05 -0400 To: Carsten Bormann Cc: xml2rfc@ietf.org References: <5f6ffc13-eaa9-c677-4c62-df55dc15e515@alum.mit.edu> From: Paul Kyzivat Message-ID: <458a69a5-6814-821e-f34c-ce86526cdf70@alum.mit.edu> Date: Sun, 26 Jul 2020 14:49:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 77cc68ef-4ddc-4326-b738-08d8319492db X-MS-TrafficTypeDiagnostic: MN2PR12MB3952: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: UH7RmuIDUAGmjfFyHZnvClyKBVD9+FxGBuVtQ8lxWAMvR7qfq5BQPeO4GnAauzyc6kbmgwXfKtR7aie8raa70IFYQSSbxR9LJPJZ/XPJudidR2h3cxHXXJkh4GAPrm87Qko4M0JqsSoxGJgNfML3BY8ySeOblqr8wgU5/LUPG83RezoHRCmRK7bEQYcCBFZLm6iYkV2OSXmMfO1i9Y3rKhwZv1diGjMd88u2iweIgFKICZUDaxkhEV7ePEQy7YDOBPA1Eo8uOYr/zXsNPuqKFC58luKg4AZtUIMy8hIRcP5WXpGc24VUB2f3C2jHFkiOJ9+AH/nS3DupCoj6OzWLKrAwHZP+omWaL/l4m+RjpQSOfF1dxrZiNApUahNyS1rYXXsxd/lwLLI7gXNA3tjKJu9RYoZb0uxGmfIyXAamwkw2aUWc4J5S2GwMjv6ySz6y X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(396003)(136003)(376002)(346002)(39860400002)(46966005)(478600001)(5660300002)(82310400002)(6916009)(356005)(4326008)(31696002)(186003)(8676002)(7596003)(70586007)(2906002)(70206006)(16799955002)(75432002)(82740400003)(8936002)(26005)(36906005)(53546011)(786003)(336012)(316002)(31686004)(47076004)(83380400001)(86362001)(956004)(2616005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jul 2020 18:49:06.0849 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 77cc68ef-4ddc-4326-b738-08d8319492db X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT007.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3952 Archived-At: Subject: Re: [xml2rfc] use of sourcecode "name" attribute X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 18:49:11 -0000 On 7/26/20 12:05 AM, Carsten Bormann wrote: > > >> On 2020-07-26, at 05:47, Paul Kyzivat wrote: >> >> In parallel with my query on the type element, I also have a question on use of the name attribute: >> >> It is described in rfc7991 as a filename. But there isn't much discussion of what syntax is permitted, or conventions. >> >> I gather that it is intended to be flexible for different environments. So for purposes of this discussion lets restrict the scope to use in IETF drafts and RFCs. >> >> Is it appropriate to use file extensions? IOW, is it a good idea to use an extension to identify the type of the content? (E.g., "syntax.abnf" and "example1.sdp".) > > As long as it isn’t “malware.php” :-) > There is some redundancy with the type here, type=“sdp” name=“syntax.abnf” sounds wrong, but then you don’t have to make this mistake. > >> What about use of "/" to introduce directory structure? > > Yes, but: > — no . or .. > - a leading / would be interpreted as relative to the RFC, not relative to the local file system (i.e., it would be ignored, or signify something else than overwriting the local system). > >> I'm thinking of how this might relate to tooling and storage. It would be nice if it was possible to have URL paths that retrieve a particular named element of an RFC or draft. > > These look more like fragment identifiers to me. > (There is no problem with fragment identifiers that collect content from different places in the document. There is also no problem with shipping a fragment identifier to a server for server-side fragment extraction as part of an API.) We have two things to coordinate here: - naming pieces of the xml (the name attribute) - referring to those named pieces (some conventions around URLs) I'm not well informed on the idiosyncrasies of URL forms. I'm happy to defer to others on the best way. But it may be that the way the URLs should be formatted might constrain or suggest ways that the names should be structured. So maybe it is worth talking about URL access to this stuff. My thinking is that the named contents of the RFC can be viewed as being contained in a directory associated with a particular document. Such a directory could actually be created at the time the xml form of the document is posted. Or it could be entirely virtual, being retrieved from the xml in realtime when a suitable URL is de-referenced. This is an implementation choice for the web site. This would for instance allow referencing abnf defined in a draft directly for feeding into a verifier or compiler. Allowing the names to be organized into subdirectories (with slashes in the names) seems unnecessary for any document I am familiar with. But I can imagine it might be helpful for a document that has *many* figures. Or, perhaps the "type" of the sourcecode could be treated as a directory, with the "name" identifying individual elements within that. That would avoid the problems of using name extensions that might be inconsistent with the "type". Thanks, Paul From nobody Sun Jul 26 11:51:16 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25E53A1416 for ; Sun, 26 Jul 2020 11:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 wSrcYj83tKfW for ; Sun, 26 Jul 2020 11:51:05 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2040.outbound.protection.outlook.com [40.107.244.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3B13A1412 for ; Sun, 26 Jul 2020 11:51:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SVx3Etm03J8JZ5PJcVEVbPRA5VFhaV5uv+11B9REZAReOoYyYS2Ch7HsKMmfztV8J4nD1TSGnOVdUcZW4G+qr0j1UNnOyonQIhl8IP0v4QLLh0d2AVqsFVs48JmKZepVCgZRwUfUOE5Azr7uPhim1R8wagDDW3KUFLGxHl56ffihOrEPhCo+YZdlLV6JvSd/o7XvN9C2gJe4zIh8QWL/RR8DOo3rbKOdBkcpStY0rr5O9pAIt7UVSTItJMf9mNvJdPpmbKWHpvLKBVQfOKsNDoYFKsfPe6SZ4MMyYPJqK1SVp6Q+nRF5oIl4FrF9x0HalOyB8vz+/60jIW902P3esg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LdeqtsJffSh6Jo4imFCU5lXQFzvxt081/hY9x2KuA4A=; b=j5AoxE18oq/RPRR3gXWqk78yZuODGHuEeQixHxyF5CrdKNXQ/PaqqeLQHJ9AuFMNt4pwfDDovr8rDzkLEwEL+4RTI3dtZ9RUprncBs98L1UBw5EWvYWhY2EYLSEHEhceY0/xIAIz8NoixRCyfhWJHQ4hGwAOtBX0lZreO+Ihl8s8UXoBEKkWxxwOL3FjSA//kGZz6MowmqhmjtU0mYMQhhs2xdpgRfkauOElzaAmZLmsvsrm3DrjVo00n8l5GMziDhdlh0Ohcm6hgBD6g4REkauACi6UKhhCh68RrUZwmJh6g71GSQrxMwOMHvtONRhbvgPHJmRMzVf3KV5UYlKm6w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LdeqtsJffSh6Jo4imFCU5lXQFzvxt081/hY9x2KuA4A=; b=NKH1VGA+R4JULf1RyM51euYxfmGRzQXJxJx7icRbETu8BjjCQvkqmdXEw6Tk7/1DArtB80Y4TW6nlkL3Tq9oyzJJP0T3HxkHfeoJ+kNvHqzt7jfCjYMXeTLuGYa1bRFdIQ9scDwG2f4dSrcb9FQueY+x0VOZ9/7odCWYBwfX5Fw= Received: from MN2PR20CA0041.namprd20.prod.outlook.com (2603:10b6:208:235::10) by BN8PR12MB3265.namprd12.prod.outlook.com (2603:10b6:408:6a::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20; Sun, 26 Jul 2020 18:51:00 +0000 Received: from BL2NAM02FT061.eop-nam02.prod.protection.outlook.com (2603:10b6:208:235:cafe::9a) by MN2PR20CA0041.outlook.office365.com (2603:10b6:208:235::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21 via Frontend Transport; Sun, 26 Jul 2020 18:51:00 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT061.mail.protection.outlook.com (10.152.77.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.10 via Frontend Transport; Sun, 26 Jul 2020 18:51:00 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 06QIowgS024410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 26 Jul 2020 14:50:59 -0400 To: xml2rfc@ietf.org References:

<234e7cfc-d4b1-a748-6092-5bb5a46a004f@gmx.de> From: Paul Kyzivat Message-ID: <21b5f4c6-222c-85ca-e3d9-3710935838c0@alum.mit.edu> Date: Sun, 26 Jul 2020 14:50:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <234e7cfc-d4b1-a748-6092-5bb5a46a004f@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6fd54f3c-d4f0-4697-20ca-08d83194d6e4 X-MS-TrafficTypeDiagnostic: BN8PR12MB3265: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xDoyA7TJDH/7Yz2d8FwePNJdWsBEwJYajELdiK/gZhZ04c5Uqgs5+5KDxnXwRpXYpQ/bjxHZpN36O+pIALpcMiPz6knT4cLBbTwc25FHZXsWT9Srth0N2Gop7IyuEmqKE4+p43vE9MgmQOG8A/kNZP150/RQ7BL6pBTfCntQ9IhNVDJHblkaaS+/6RZW/DOifAjItutjqVZ4SoZ532rOEgcvwg4fnZTPcmr6946ziihK4NJmWCwYKdBQHaVRFrM4A1HFuAu+OTAl1zpnm6Bg+nI0sVuj3yhbpKOjibzyuEf/fttoPzjs3AuOVuP3+O+xKEqMM/awmvWx+JBEaTYqjDObAZbT7tcyZAgHVhHzkxOAgSkGneOUfLLf6hsb3SMGhEFBR5kYjsXLdvynkePLBfnZLcfujAf2/82VLzY61ycAhTh/TgDq0PbtZQu67gFywlwNa/PvxDwLrIgJitW3rFswTB44TCmIApplLz2NcCA4zzXyKFnE+JscnknVl/p3 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(346002)(396003)(136003)(39860400002)(376002)(46966005)(2616005)(82740400003)(336012)(786003)(478600001)(7596003)(956004)(4744005)(2906002)(36906005)(70206006)(316002)(70586007)(47076004)(356005)(8676002)(31696002)(75432002)(53546011)(86362001)(8936002)(31686004)(82310400002)(6916009)(186003)(5660300002)(26005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jul 2020 18:51:00.1861 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6fd54f3c-d4f0-4697-20ca-08d83194d6e4 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT061.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR12MB3265 Archived-At: Subject: Re: [xml2rfc] use of sourcecode type X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 18:51:13 -0000 On 7/26/20 3:16 AM, Julian Reschke wrote: > Am 25.07.2020 um 19:07 schrieb Paul Kyzivat: >> This long discussion may be helpful and lead to some clarification that >> will be useful in the long term. In the meantime I still need to decide >> what type I should be using for *fragments* of SDP. Should I just use >> "sdp", or take a flyer with something like "sdp+fragment"? I'm in >> AUTH48, so I can't dawdle here. >> >> (In this usage the fragments aren't intended to combine into a >> meaningful whole - they are generally previews. There is one sourcecode >> element at the end that contains the complete SDP syntax.) >> >> Thanks, >> Paul > > In any case, In which case? > this should be tracked at > . Which "this"? the general issue, or my particular need in the short term? Thanks, Paul From nobody Sun Jul 26 12:48:39 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEE63A0991 for ; Sun, 26 Jul 2020 12:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 7TYQH4F21DBf for ; Sun, 26 Jul 2020 12:48:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7E43A0980 for ; Sun, 26 Jul 2020 12:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1595792911; bh=W4Nt9SOBH/RiyC6C6lmqUnpWCZ7dv/1diftEUwJbdlQ=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=En2sxhEcxEFNDZB5ttIf6cmpvyl2XUoKy4JZcCLwKnlrVC0waVkioM4NVoXjRH12q gOnyn2JQkiicQDrTqXYCS0YgIjiVuAnkBFwlz9VWbZbwriKNZQ88wc5xzvn3XJJ/+M WqRpOsnBMekELVmVlGwI06HDLw11tGGpg69nQO2g= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.182] ([84.171.145.184]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mr9Fs-1kchlR18hq-00oFSe for ; Sun, 26 Jul 2020 21:48:31 +0200 To: xml2rfc@ietf.org References:

<234e7cfc-d4b1-a748-6092-5bb5a46a004f@gmx.de> <21b5f4c6-222c-85ca-e3d9-3710935838c0@alum.mit.edu> From: Julian Reschke Message-ID: Date: Sun, 26 Jul 2020 21:48:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.0.1 MIME-Version: 1.0 In-Reply-To: <21b5f4c6-222c-85ca-e3d9-3710935838c0@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:wGJFBviZGN+RDFaC1ffKrU6lDDTUMptNQizcu/qa3aDtv9IEIpi 4KEg/XAy2tNjE56oeJFiA2qS91F12gJBtWVGqYz4LqQ1mwzJGKzd0I0RMlez4tm8/pUGR8W AqB78wV4+QOw89TyjtCBAoSPcAGqWNZvV/622BDjSFQdUsfuMCd2mDjANxs4aHDhBZ2Bz3I d7xNd26XFon6uhP+iwR8Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:+64+L7cuBn4=:Yx/2/MlLoCqhtWjzPWsDW+ SE2YLkpFfFlBOw7cX3d+8Vf27/xbSi53pnOGUgdQ3cqWCPWFDuvfd6jxnYAw58Sf1J4QcKoqA T896jTrOLo2BbGR+PoevEnhXqI1+fKndLjthikkuc+7NxAaGXcr1VyvCOyjBpCiWvO7El/zNe lPYlEz57lc+8BPLg6fu2I1MXgv9gLebp2XloYfu7KW3Sp0fRs/GEY/AvCtroaOvAJQKW/0cIa 9/bw7QP90795UDss+2PoPohEet0KBTukX3n5oNiUgbI1axv93N9XJlyRMeOjmR9GlzNuT7Ukb XX4xIQy4YONv0wQ9kpjn45wIUqDAlv97bLWO7Vosh0kmH7062MbMI6ZLfkhqORS2HJ9Rv6MaQ GUhoQ+0V+WzPG9XiaKQASeRSlcDBBrPo46+infOhuOpouWW3XUR9FVIaba8jgdqk3jBBAOBov IGMc3azSobQ3qRYBTXvx5bYy0AEif0VbnqkRDZ7C141yyEgB1TPG6gxWJ2whZzoZZj9ZrYAca AQVGJh5+Gf560j6zkD8gRL/fV8ifAblWCkIFWPdYh70HmKNQXhUNh/T2u/AtNUbwKE+RLHCzV fj+kLcgP20tFPdmp8VZzoSH8I8VewQ4PS3jBPZzIPBlFsLUHa8zAkk9sjNHJeDegNHi30E9tA 2JXtkFb4Tc4AwHxR0SZsXgpGW99hReVZtkZxH8x5vMz1kFvesp0fnLSSQzSsago6S/gdeTo7j pDkHkOBEu8kx6vFkeelEy8GnxYenOuc8gEBZKPqUmy9HU6yo1wol37hwipXEmox2yzlFi/FgK sSbOZcRIGC7P0LM4/nRg5oj/ZDCwY9ZkaJKm3C+67gHiTPC5PJxANWXJYYbopPMMUtgtwjnnK xrwqV3OJ2Y8MfPOoAZ6FogwJzKZetxw1EdLVOyjg/JQv5lXHwnIWKSTE0fhIcNiBkYkcVXL3j zChsbmO2ldP4pccGkLxT/HDZbyEZ+ptC4GrMQL4KVBaTg++ODFK51hqzyzT9DLp1yffAKitcb 2xYzfPqNqGgtN9ZYGKItR+UP79icti9ipLyimgyFZLY8JGktVtErYK7uxP45DnJ6ReQkaW/eY IVHIvDXEg5hhdMptc5if0CNpgCYulfylJvaHMIxQF7pi1LMxKd0nIKuaEkDH6GheZdsh9ASCF Lok0IkyS7U8wdGXuyjJQl/u28u9uoScpPbULbY470jKyhbv3+UAyHel80qCloHHz/ZsqO1ZXp HLGFoeo7U+hsPOHdD0UiKLSCNx35z4lolY3qqmg== Archived-At: Subject: Re: [xml2rfc] use of sourcecode type X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 19:48:39 -0000 Am 26.07.2020 um 20:50 schrieb Paul Kyzivat: > On 7/26/20 3:16 AM, Julian Reschke wrote: >> Am 25.07.2020 um 19:07 schrieb Paul Kyzivat: >>> This long discussion may be helpful and lead to some clarification tha= t >>> will be useful in the long term. In the meantime I still need to decid= e >>> what type I should be using for *fragments* of SDP. Should I just use >>> "sdp", or take a flyer with something like "sdp+fragment"? I'm in >>> AUTH48, so I can't dawdle here. >>> >>> (In this usage the fragments aren't intended to combine into a >>> meaningful whole - they are generally previews. There is one sourcecod= e >>> element at the end that contains the complete SDP syntax.) >>> >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Thanks, >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Paul >> >> In any case, > > In which case? In this case, and in others where we discuss shortcomings of RFC 7991. The replacement document is under development, and has an issue tracker. > ... Best regards, Julian From nobody Sun Jul 26 13:36:20 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD5C3A1455 for