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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 05 December 2016 19:17 UTC

Return-Path: <rfc-interest-bounces@rfc-editor.org>
X-Original-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Delivered-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874E5129B74 for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Mon, 5 Dec 2016 11:17:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.984
X-Spam-Level:
X-Spam-Status: No, score=-6.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=gmail.com
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 qkw5oukPtpIy for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Mon, 5 Dec 2016 11:16:58 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99712129563 for <rfc-interest-archive-eekabaiReiB1@ietf.org>; Mon, 5 Dec 2016 11:16:58 -0800 (PST)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id 5615DB8039E; Mon, 5 Dec 2016 11:16:58 -0800 (PST)
X-Original-To: rfc-interest@rfc-editor.org
Delivered-To: rfc-interest@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 9D6F8B8039E for <rfc-interest@rfc-editor.org>; Mon, 5 Dec 2016 11:16:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Authentication-Results: rfcpa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arhMAzMCfy8h for <rfc-interest@rfc-editor.org>; Mon, 5 Dec 2016 11:16:55 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) by rfc-editor.org (Postfix) with ESMTPS id 52F28B8039C for <rfc-interest@rfc-editor.org>; Mon, 5 Dec 2016 11:16:55 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id d2so65112100pfd.0 for <rfc-interest@rfc-editor.org>; Mon, 05 Dec 2016 11:16:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=t8gihoW+a6pv2BKjRXOYowfvTy6SsNqRXd1d3rn97+o=; b=JmjoDAPGmqDEmgQHJQLbNvzbQNvAi2XqLJTaF79aSjuWb09L9aOj9PpfzbiJ+dxki+ RwaPQA7Sbc9rKCYoscWciqceJUOuU+yw6iomI0Akp0xuuHU+SC/9nx+9cNhuV+KiCmBq MTidLCo/qXCwAjKmHvtfyFwWgC/fqYRX5Xw2GW3SgSTlaRLnhhAUDTM1AOM45fTx0zA2 8RfZ73LIg3nMt0JeRDPk2ZjHyihVL9igjiWhM00xbXMtWmD5sUYnSFGQ7P5FPtwv5NUP d5ia47w9zvNgUSWJ9GflkK1KNxNEiuvyxZjjBl4XYVRloTWoLH6vW3AejtY80I40xyxs BMJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=t8gihoW+a6pv2BKjRXOYowfvTy6SsNqRXd1d3rn97+o=; b=LVNIpDdiDyvtmyZhR/chk1snkm3FB+oyGhmnl6pTENaRzWjZy26P9wFNkpDvzGOI/u xZf/D4CDE6NzZ4IBB+NInQhrx+ViadZYumD5GsGSdI/JwliEzKYU2VR+YdIVsRNojgFF CDk8y9e0a3f03DUE2XxVlIfX94slUif6P+LeNWfooKg0VuJ9TUqYfQD6aCVcwAUa84jp +Nwc8nVCzvVHaoTH9KlH19/bWDQ1rEPBwJrIWztWvUvj9xT+P7g/bMeY3nC02L0T89uL NAMWGM9gSLXOAqpF7pVWysJ2HhaJW1RWkdJGRMihsXoaXAZuC5jKMxW43xpHe13Xvkij sfqQ==
X-Gm-Message-State: AKaTC00r5IPz4RbVC2DJ0fWOAaGL53Q9xcrzaYklAE376y+5ZY5wUOmb/HbBqsIuW4JIpA==
X-Received: by 10.84.217.20 with SMTP id o20mr128702592pli.28.1480965414833; Mon, 05 Dec 2016 11:16:54 -0800 (PST)
Received: from [192.168.178.21] ([118.148.117.234]) by smtp.gmail.com with ESMTPSA id p64sm29153701pfi.88.2016.12.05.11.16.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Dec 2016 11:16:54 -0800 (PST)
To: Russ Housley <housley@vigilsec.com>
References: <20161202221919.7465.qmail@ary.lan> <e46334f6-3e0b-809e-8a5f-1a3784ebf588@gmail.com> <F3E7B5C3-C4AF-4DDF-872C-451FD8E59307@vigilsec.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <d225b5da-c80e-6b69-ed3d-8cafcdd941df@gmail.com>
Date: Tue, 6 Dec 2016 08:16:52 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <F3E7B5C3-C4AF-4DDF-872C-451FD8E59307@vigilsec.com>
Subject: Re: [rfc-i] Request for feedback: the new CSS
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
Cc: RFC Interest <rfc-interest@rfc-editor.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: "rfc-interest" <rfc-interest-bounces@rfc-editor.org>

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

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".)

    Brian

_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest