Re: [rfc-i] Table of conformance requirements.

Larry Masinter <> Thu, 18 June 2020 17:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D406F3A0A6C; Thu, 18 Jun 2020 10:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dwzOiysT9H3C; Thu, 18 Jun 2020 10:17:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D75BF3A09F1; Thu, 18 Jun 2020 10:17:35 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 1B9A4F40709; Thu, 18 Jun 2020 10:17:30 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B0A4F406F6 for <>; Thu, 18 Jun 2020 10:17:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E2KIjxq2i3Ot for <>; Thu, 18 Jun 2020 10:17:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id A511EF40718 for <>; Thu, 18 Jun 2020 10:17:24 -0700 (PDT)
Received: by with SMTP id j12so848053pfn.10 for <>; Thu, 18 Jun 2020 10:17:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=vZ3pxZgCPn+0wERKGiaNSUqk59MAnwDxwVT1W6jaxgc=; b=CyeX008oB6fJPnFLhOp1BVlnYgHzEe+HY9EB4x3wwXknqzQ/XtGsSBwqKn0p1TAwdV z835/CfCxTD/nXC0iY1qxVbtQY2EjV4Jo2jeAdAseNaoZbWbilBvvsNEiZ9z2doXn0GB gXAJNN0B2ttyb8B/57ITazczUnK5tl13SDXN2X7fqkUYBZL0rLdZeNy7jzWJvxFiZemV nGJQp9GNnG6K/HQ5Tm6KP5Ls7g7spRuDGVl3yUk31r/yZZmQ+N87eZr1h5k0/1WE2kXV au+HIZ117Z82bDZubCsFmRObo8ZXneVfQDLzgIUcYdFlmj8vWRufnGN3hLkrHYME2xnK RouQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-language:thread-index; bh=vZ3pxZgCPn+0wERKGiaNSUqk59MAnwDxwVT1W6jaxgc=; b=duK06VFHmkx6YBpkiihxkFvWazEnwlvjff01wDWN53EKqsr931RTMjhng0aRAgoHkL KgkCMe7kBBVe18SDyllaQwHoawQ3nRo38dt5MOWEw7Gxehk3j9AE5EM4nEh9bRbQRuhy vZpJ/wdhrkUnUZys06rcz8sdEcWIGAaX17+THlsgJaVOdVqZ2ln/gz72bivPbcj8Ao8r ku9oxJUt/hMHjf30/rajGGM8vEme35bkwWLiJZCAs3iJs+xKmgr9gc2Jmj20elDfyt6P 02C7ZW9b/KKb7o8P6i66cT4FVFDfKUxsQcgr6R+6vYkQ2jSBCOcP8xPeRn6ZvqYfXprJ k/NQ==
X-Gm-Message-State: AOAM531ZjM2HzOLu9NVQsme/VP5zDMuB+asWj9/d0HBDD1eF3kK7mvPc QVlG4iK3PQrPTD1lKX5Bw2E=
X-Google-Smtp-Source: ABdhPJw3cU5NX2NBrIC0AiDsns17R5kW6WctEU1pv6kI2A9w2oWXoFl4YrBDCl8cmxUY656vCFz4sw==
X-Received: by 2002:a62:9246:: with SMTP id o67mr4333815pfd.109.1592500589528; Thu, 18 Jun 2020 10:16:29 -0700 (PDT)
Received: from TVPC ( []) by with ESMTPSA id z24sm3497833pfk.29.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 10:16:28 -0700 (PDT)
From: Larry Masinter <>
X-Google-Original-From: "Larry Masinter" <>
To: "'Christian Huitema'" <>, "'Robert Sparks'" <>, <>
References: <> <> <> <007a01d6458d$9e469760$dad3c620$> <> <>
In-Reply-To: <>
Date: Thu, 18 Jun 2020 10:16:27 -0700
Message-ID: <00d901d64594$34439910$9ccacb30$>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQKsY7PWm7dz3N0N9w3eZk85D/xO4ALKabyUApBqIBMCAkm44AHHDXEkAYJ3Ll2m3STG4A==
Subject: Re: [rfc-i] Table of conformance requirements.
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============9084978308202992850=="
Sender: "rfc-interest" <>

At the time, and also now, being clear enough about conformance requirements would be a requirement for the STD series, not the RFC series.


Given that you can’t just concatenate XML of separate RFCs to make a STD which has more than one component, there is a need for some other kind of way of specifying Internet Standards.

I imagine  Internet Standards which are a document series which might start out as pointers to the relevant RFCs (and errata) but which could be updated as the standard evolved.





 <>  <>


From: rfc-interest <> On Behalf Of Christian Huitema
Sent: Thursday, June 18, 2020 9:42 AM
To: Robert Sparks <>om>; Larry Masinter <>rg>;
Subject: Re: [rfc-i] Table of conformance requirements.


I think Robert's example shows the limit of the exercise. Take this requirement from the list:

  MUST-3: There are certain operations that an application **MUST** be able to perform when interacting with QUIC streams.

How are you going to test that snippet of text? In the original document, what follows is the list of these operations that the application is supposed to perform. But if you just take out of context the snippet of text surrounding the MUST statement, you get something meaningless.


-- Christian Huitema


On 6/18/2020 9:31 AM, Robert Sparks wrote:

On 6/18/20 11:29 AM, Larry Masinter wrote: 

A previous proposal 
and experiment 

Yeah, well. Fwiw: 


-----Original Message----- 
From: rfc-interest  <> <> On Behalf Of 
Robert Sparks 
Sent: Thursday, June 18, 2020 6:38 AM 
To: <>  
Subject: Re: [rfc-i] Table of conformance requirements. 

I have a script that builds such lists, and have used it for 20-ish years at this 
point in various contexts. 

Some example output: 

For the most part, its best use has been to help identify when there are 
meaningless, duplicate, or contradictory uses of the BCP14 keywords. 

In interop testing (primarily the SIPit), having these requirements 
enumerated this way didn't help drive test behavior or the creation of test 
suites. It turned out that far more context was needed as a predicate to "I'm 
going to check this thing" than the isolated sentence containing the 
requirement. And agreeing on that context often turned out to be a 
subjective exercise (when that happened, I'd help put pressure on changing 
the spec to reduce the probability of different interpretations). 

So, it's been somewhat helpful in my experience, but not helpful enough to 
try to build extra support for it into, say, the v3 grammar. 


On 6/18/20 2:08 AM, Carsten Bormann wrote: 

There is a whole industry around requirements tracking. 
I’m sure the Ribose people can tell us more about that. 

Each MUST in a specification should have at least one corresponding unit 

test to check compliance. 

Yeah sure. 

RFC 4120: 
     *  Principals MUST keep their secret keys secret. 

I’d love to see that unit test :-) 

The other problem is that we simply don’t state all requirements in BCP14 


Very often, most requirements are stated in describing an architecture or a 

protocol; they are phrased as statements of fact.  Extracting and labeling 
these requirements for requirements tracking is an art form. 

And this needs to be expressible somehow in XML. 

I played around some with using kramdown’s auto-indexing feature for 

BCP14 keywords.  With today’s xml2rfc, that gives you an index of BCP14 
usage.  Not exactly what you want, but just a few lines of kramdown 

I never used the results of these experiments in a document, mainly 

because the lack of BCP14 language on so many of the actual requirements 
made the result too sketchy. 

Grüße, Carsten 

rfc-interest mailing list <> 

rfc-interest mailing list <> 

rfc-interest mailing list <> 

rfc-interest mailing list