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

Brian E Carpenter brian.e.carpenter at gmail.com
Mon Dec 5 11:16:52 PST 2016

On 06/12/2016 06:18, Russ Housley 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.

I understand that. I think there's a broader issue though. Throughout the TLP the word "text" is used to refer to the contents
of an IETF document. IANAL but don't we need some words that will prevent
ambiguity when the canonical form changes from plain text? (Yes, you and I know that XML
is written in text, but I'm not sure that all lawyers, judges and even juries will get that,
or be prepared to treat XML tags as part of the "text".)


More information about the rfc-interest mailing list