Subject: [Xml-sg-cmt] documenting usage guidance for <bcp14> tags

From: Sandy Ginoza <[email-masked]>
Date: Thu, 4 Feb 2021 15:54:43 -0800

Hi John,

FYI - bringing the xml-sg team in on this, because I’m not sure if documentation defining <bcp14> needs to be updated. 

I’d like to clarify whether <bcp14> is limited to use for requirements or is it author preference?  Also, I’m wondering where is the best place to document this guidance?  Ideally, the authors are aware of this info because the use of keywords is a technical decision.  

Two possible places to document usage guidance come to mind:
https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-bcp14-2
https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html#section-7.13

Please note that <bcp14> tags were not an option prior to v3.  The RPC is using a script to add them to the keywords in each document.  I think we could ask authors to review <bcp14> tags in the AUTH48 notification mail, so <bcp14> tags would be removed upon author request.  Please let me know if you have any concerns with this approach.

Thanks,
Sandy 

> Begin forwarded message:
> 
> From: "John R Levine" <[email-masked]>
> Subject: Re: [RSE] Re: final question - Re: [ADs] AUTH48 [KC]: RFC 8941 <draft-ietf-httpbis-header-structure-19.txt> NOW AVAILABLE
> Date: February 1, 2021 at 11:59:18 AM PST
> To: "Sandy Ginoza" <[email-masked]>, "Mark Nottingham" <[email-masked]>
> Cc: "Poul-Henning Kamp" <[email-masked]>, "Barry Leiba" <[email-masked]>, "Poul-Henning Kamp" <[email-masked]>, "Tommy Pauly" <[email-masked]>, [email-masked], "RFC Editor" <[email-masked]>
> 
> On Mon, 1 Feb 2021, Sandy Ginoza wrote:
>> We suggest using <bcp14> in the example because it makes the example more complete, but I’m bringing John into the discussion to make sure we’re doing the right thing.
>> 
>> This is where <bcp14> is described:
>> https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-bcp14-2
>> 
>> However, I don’t think this exactly answers the question of "If the markup is intended to assist in finding relevant requirements”.
>> 
>> John?
> 
> Well, of course, this is a context nobody thought of when we wrote the vocabulary.
> 
> My inclination is to reserve it for actual normative language, so people can use it to try and extract the requirements from RFCs.  Since this is an example, I would not use it here..
> 
> Regards,
> John Levine, [email-masked], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly

---

From: Sandy Ginoza <[email-masked]>
Date: Mon, 8 Feb 2021 16:54:13 -0800

Hi Mark, 

Please note that I’m adding the XML and Style Guide team to the thread so they are aware of the question and can potentially offer more input here.  

> On Feb 8, 2021, at 3:57 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Thanks again, Sandy.
> 
> One thing - when I run the XML through Julian's XSLT, it gives the following errors:
> 
> ERROR: artwork or sourcecode contains HTAB character
> ERROR: artwork or sourcecode contains HTAB character
> ERROR: artwork or sourcecode contains HTAB character
> 
> Is that an issue?

We believe these errors are produced from the not prepped XML file <https://www.rfc-editor.org/rfc/prerelease/rfc8941.notprepped.xml>, as opposed to the final prepped XML file <https://www.rfc-editor.org/rfc/rfc8941.xml>.  The tabs on 3 lines of the not prepped file (i.e., lines 256, 264, 269) are not present in the prepped XML file.  For the not prepped XML, the tabs a) do not cause any warning from xml2rfc and b) do not cause any effect in the output files.

Thanks,
Sandy 

> 
> Cheers,
> 
> 
>> On 9 Feb 2021, at 10:54 am, Sandy Ginoza <[email-masked]> wrote:
>> 
>> Thanks for your reviews and patience!  The RFC was just announced.
>> 
>> https://www.rfc-editor.org/pipermail/rfc-dist/2021-February/005791.html
>> https://mailarchive.ietf.org/arch/msg/ietf-announce/A8YR30x2ZiW5B4qqTV1f1F-emq0/
>> 
>> 
>>> On Feb 4, 2021, at 11:41 PM, Poul-Henning Kamp <[email-masked]> wrote:
>>> 
>>> --------
>>> Sandy Ginoza writes:
>>> 
>>>> Please let us know if we may proceed with publication.
>>> 
>>> Ok with me.
>>> 
>>> -- 
>>> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>>> [email-masked]         | TCP/IP since RFC 956
>>> FreeBSD committer       | BSD since 4.3-tahoe    
>>> Never attribute to malice what can adequately be explained by incompetence.
>>> 
>> 
> 
> --
> Mark Nottingham   https://www.mnot.net/
>

---

From: "John R Levine" <[email-masked]>
Date: 10 Feb 2021 13:25:59 -0500

> Please note that I’m adding the XML and Style Guide team to the thread so they are aware of the question and can potentially offer more input here.

In published RFCs I see lots of tabs in <t> and <dd> but not in <artwork>, 
so I believe Sandy is correct, it will go away in the prepped published 
version.

Regards,

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Feb 2021 09:38:25 +1100

Thanks!

> On 11 Feb 2021, at 5:25 am, John R Levine <[email-masked]> wrote:
> 
> In published RFCs I see lots of tabs in <t> and <dd> but not in <artwork>, so I believe Sandy is correct, it will go away in the prepped published version.
>