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

Martin Thomson <mt@lowentropy.net> Thu, 23 July 2020 01:38 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 133673A0AFF; Wed, 22 Jul 2020 18:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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=lowentropy.net header.b=A+xhwIHj; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=messagingengine.com header.b=McMndCJb
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 ZOEO-64sEpJx; Wed, 22 Jul 2020 18:38:05 -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 8C1B63A0AFD; Wed, 22 Jul 2020 18:38:05 -0700 (PDT)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id 165DEF40755; Wed, 22 Jul 2020 18:37:49 -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 5A084F40755 for <rfc-interest@rfc-editor.org>; Wed, 22 Jul 2020 18:37:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Authentication-Results: rfcpa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=A+xhwIHj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=McMndCJb
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 BVcSbz1GcNpH for <rfc-interest@rfc-editor.org>; Wed, 22 Jul 2020 18:37:43 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by rfc-editor.org (Postfix) with ESMTPS id DCF00F4074D for <rfc-interest@rfc-editor.org>; Wed, 22 Jul 2020 18:37:42 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4BBEF5C00A5 for <rfc-interest@rfc-editor.org>; Wed, 22 Jul 2020 21:37:58 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 22 Jul 2020 21:37:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=afeOD 1I1/NBi32+Ndv8SQ7eCT3hklhisBz26UEG8Ni4=; b=A+xhwIHjuPB9ZcAbrkT0U fzRN7GUdGeWZjkLhousIy1A4eJFbVFYkZytcXOINfjCiIINrxVVz4Ged1WT/M2tK 0nw2x0bkjBMmYpBr4CDEX5tmJg3Lxmgh1ttiMp6fAwrMi92d4Xn0r0Q3kW0qjZSK 6RD3rc1CuwulHrMxmbUeoMs7OHwl30gYLCCn3IhoAytzBqbKex10GShGm1PSGV7i md/i2Bl9uY2+SCZ0cI3Fy+aHu+2EcWH3UtlQKTMti+sm8CbYtyBZzvGtek7n8gGL bmkYx3RVhDqHKx/w/tDNiHlK7aWP8a3ol8JhsLzBh2EusPL54McUm+cqWik+kWiW w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=afeOD1I1/NBi32+Ndv8SQ7eCT3hklhisBz26UEG8N i4=; b=McMndCJbeqWvrBsdhfZ5HV2IDrx6bK3cRLOdVxKs+otPnqFWh9wj1EMK/ xp7RmPW6/UDowwV4a38ky+6//R4ZMQPq6oSzhJ70KbOC8d+yTdaXVqKS1VNrgQop ph7v3BOS77JQu9K9LfW2oiBsSph0ujUhK0SekN6FaE/HFJUDUAyJcofmpdCki3lh PgmlZ8URohg8E8Ss5Vv60JBjSrby8wh2rBBHbLTE2o2nkrSyOcjthtHOU+jBv41F 7Q1mCRAclHGafOpsAFt6KsfzG84Fyw/WKP3Hky+Rcr9WJOIRwtGc1Uhys08GKN1L pM644DWNtfmJw60DJB3XdmyaOmzhQ==
X-ME-Sender: <xms:9OkYX9R1UOLV-S3pz29SnYdW0T9DuKgYV6z9dznoE6ptHdNTqIJbnQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrhedtgdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeeuieeugeettdegveegge ffgeeuiedufffhjeeuvdelvdeuuedtvdffjeeltdetudenucffohhmrghinheprhhftgdq vgguihhtohhrrdhorhhgpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght
X-ME-Proxy: <xmx:9OkYX2y_hGXWq0FMREvBWyoqDeE6uyqb2m3iZ1d5olaKw3XtOpSCjQ> <xmx:9OkYXy3hcJTgbN4mSM_NYqi1jpeZ_wz2tiu_KbLjvI1lE5ClZDD_qQ> <xmx:9OkYX1C6vX4eRlW6huQCCbHa4LokzkfWWRgWOGuumVzY5Igtr8Uewg> <xmx:9ukYXxS6qRN9cQdCtzhpnWAFcWh69lHni7xwqXiTxeAeStr6CeTd_A>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id BDDF3E00A8; Wed, 22 Jul 2020 21:37:56 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-92-g11c785d-fm-20200721.004-g11c785d5
Mime-Version: 1.0
Message-Id: <71455ac8-14b1-45a7-a27f-bdeb50ed1917@www.fastmail.com>
In-Reply-To: <748F0BE8-5DDA-4CC1-9306-0C67F906C955@tzi.org>
References: <e13ad2a9-e460-58cb-3ffe-88acec803a8a@alum.mit.edu> <748F0BE8-5DDA-4CC1-9306-0C67F906C955@tzi.org>
Date: Thu, 23 Jul 2020 11:37:35 +1000
From: Martin Thomson <mt@lowentropy.net>
To: rfc-interest@rfc-editor.org
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>
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>

In rust documentation, there is a flag for example code that says "this code is invalid".  That is separate from the (implied) type.

I don't see it being necessary to fix the "this is invalid, but it is if you add it to this other thing".  But that might be fixed with an excerpt flag that says "this is an excerpt (from X?) and therefore not valid on its own".

As for IANA maintaining a registry of types, sure.  I had no idea that this was a thing until the tls-syntax tag was added by the editor to one of my drafts.

On Wed, Jul 22, 2020, at 01:10, Carsten Bormann wrote:
> 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
>
_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest