[rfc-i] Request for feedback: the new CSS

Scott O. Bradner sob at sobco.com
Mon Dec 5 11:17:14 PST 2016

I asked Jorge and he said the same thing - the tags are optional


> On Dec 5, 2016, at 12:18 PM, Russ Housley <housley at vigilsec.com> wrote:
> On Dec 2, 2016, at 5:37 PM, Brian E Carpenter <brian.e.carpenter at gmail.com> wrote:
>> On 03/12/2016 11:19, John Levine wrote:
>>>>>> 1. You have some embedded code fragments. Is it your intention that these will
>>>>>> still be visibly marked <CODE BEGINS> and <CODE ENDS>?
>>>>> As far as I know, those markings are optional, right?
>>>> Not exactly. And they aren't our choice - they are defined in the IETF Trust
>>>> legal provisions:
>>>>>>> License to Code Components.
>>>>>>> Identification. Text in IETF Contributions and IETF Documents of the types
>>>>>>> identified in Section 4.a above shall constitute “Code Components”. In addition,
>>>>>>> any text found between the markers <CODE BEGINS> and <CODE ENDS>, or otherwise
>>>>>>> clearly labeled as a Code Component, shall be considered a “Code Component”.
>>>> So regardless of what would be most elegant in XML2RFCv3, authors must be able
>>>> to include these labels explicitly.
>>> I see the phrase "or otherwise clearly labeled as a Code Component"
>>> which suggests to me that we don't have to use the ugly bracket things
>>> if the document says something like all the blocks of fixed pitch text
>>> are code components.  They're still coded in the XML so mechanical
>>> extraction is no problem.
>>> For that matter, I'd argue that since the XML is the canonical format,
>>> the XML code markings clearly label the code and we're done.
>> Yes, that *ought* to be the case, but I would much prefer to see the Trust legal
>> provisions modified accordingly. It's going to be complicated enough persuading
>> lawyers and judges that XML is more canonical than plain text, without also
>> expecting them to re-interpret the Trust text as well.
> There are many, many RFCs that do not use <CODE BEGINS> … <CODE ENDS>.  That is the reason that these marks are optional in the Trust Legal Provisions.
> I think it is pretty clear when ABNF, YANG, ASN.1, C, Perl, and so on are used.  I do not think we want to make a change to the Trust Legal Provisions based on the ability of the use a different style as an alternative way to mark code.
> Russ
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

More information about the rfc-interest mailing list