Re: [rfc-i] [xml2rfc] use of sourcecode type

Carsten Bormann <cabo@tzi.org> Tue, 21 July 2020 15:10 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 9E69D3A0A31; Tue, 21 Jul 2020 08:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level:
X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 i1vW263gk3Fs; Tue, 21 Jul 2020 08:10:29 -0700 (PDT)
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 3F7913A0A93; Tue, 21 Jul 2020 08:10:29 -0700 (PDT)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id 44652F4074D; Tue, 21 Jul 2020 08:10:15 -0700 (PDT)
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 1270FF4074D for <rfc-interest@rfc-editor.org>; Tue, 21 Jul 2020 08:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
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 D6c8WHV9eYDt for <rfc-interest@rfc-editor.org>; Tue, 21 Jul 2020 08:10:10 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) by rfc-editor.org (Postfix) with ESMTPS id D1ED5F4073C for <rfc-interest@rfc-editor.org>; Tue, 21 Jul 2020 08:10:09 -0700 (PDT)
Received: from [172.16.42.100] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BB28V6Kg4z103j; Tue, 21 Jul 2020 17:10:18 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <e13ad2a9-e460-58cb-3ffe-88acec803a8a@alum.mit.edu>
Date: Tue, 21 Jul 2020 17:10:18 +0200
X-Mao-Original-Outgoing-Id: 617037018.1169651-c3686bd7a4c6f65304a6a452a125e97d
Message-Id: <748F0BE8-5DDA-4CC1-9306-0C67F906C955@tzi.org>
References: <e13ad2a9-e460-58cb-3ffe-88acec803a8a@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Subject: Re: [rfc-i] [xml2rfc] use of sourcecode type
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.29
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: XML2RFC Interest Group <xml2rfc@ietf.org>, 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>

A similar problem is giving examples that are intentionally bad in order to demonstrate a kind of error.

I typically tag them with a type that is derived from the one I would give for real code, e.g., “CDDLx” for a bad CDDL example.  I think it would be good to agree on some way to indicate this.

A related problem is that often several code blocks combine to one valid instance of CDDL, for example see Figure 1, 2, 3 in RFC 8428.  There is no way to say that Figure 1 and 2 combine into a valid instance, and so do Figure 1 and 3, but not any other combination.

And, by the way, those type tags are conventionally lower-cased, but this is not made very explicit; you have to infer that from the list in Section 2.48.4 of RFC 7991 or the RFC editor’s updated copy of that list:

https://www.rfc-editor.org/materials/sourcecode-types.txt

(Ha, this doesn’t even have “cddl” in it; I’m not sure how this is updated and whether there shouldn’t really be an IANA registry for these.)

Grüße, Carsten


> On 2020-07-21, at 16:36, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> I have a question about specification of type in sourcecode elements:
> 
> In RFC4566bis there are many examples that have fragments of SDP. But they aren't compliant to SDP syntax, since it requires that many things be present - that are intentionally omitted from these examples.
> 
> Is it valid to tag these with type="SDP"?
> 
> (In sip we had a similar problem. There is a mime-type message/sip, but we sometimes also return fragments of sip in error messages. We ended up defining a separate message/sipfrag mime-type for this.)
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@ietf.org
> https://www.ietf.org/mailman/listinfo/xml2rfc

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