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

On Dec 2, 2016, at 5:37 PM, Brian E Carpenter <brian.e.carpenter@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@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest