[fdt] Fwd: [CFRG] XDR in RFC8391

Carsten Bormann <cabo@tzi.org> Wed, 02 December 2020 12:43 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: fdt@ietfa.amsl.com
Delivered-To: fdt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFA53A138D for <fdt@ietfa.amsl.com>; Wed, 2 Dec 2020 04:43:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 h-Mi0csgsehP for <fdt@ietfa.amsl.com>; Wed, 2 Dec 2020 04:43:20 -0800 (PST)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592C03A138F for <fdt@ietf.org>; Wed, 2 Dec 2020 04:43:18 -0800 (PST)
Received: from [192.168.217.118] (p548dca87.dip0.t-ipconnect.de [84.141.202.135]) (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 4CmJXw3TDyzyXP; Wed, 2 Dec 2020 13:43:12 +0100 (CET)
Content-Type: multipart/alternative; boundary="Apple-Mail=_25FF8066-6E2F-41E2-BBF3-6AA60ED6DE1D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Carsten Bormann <cabo@tzi.org>
Date: Wed, 02 Dec 2020 13:43:12 +0100
Cc: andreas.kretschmer@siemens.com
X-Mao-Original-Outgoing-Id: 628605792.089592-901d2b82baef039a0bb03b348db1480e
Message-Id: <6AADD8B6-FC12-4B68-9C60-B8D92C7D366D@tzi.org>
References: <VI1PR10MB22850F4780CA2E97A7EA18F795F30@VI1PR10MB2285.EURPRD10.PROD.OUTLOOK.COM>
To: fdt@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/fdt/3LGYgZsCdtswHoPF6GnWE1D7r3Y>
Subject: [fdt] Fwd: [CFRG] XDR in RFC8391
X-BeenThere: fdt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mailing list for the discussion of the use of formal description techniques in IETF documents <fdt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fdt>, <mailto:fdt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/fdt/>
List-Post: <mailto:fdt@ietf.org>
List-Help: <mailto:fdt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fdt>, <mailto:fdt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2020 12:43:24 -0000

Apparently there was another failure in checking a formal definition before publication.
(Note that RFC 4506 in turn doesn’t use ABNF to define XDR specification syntax.)

I think the third item isn’t a problem; the text in 4506 just seems to lack an explanation for the apparent fall-through-like meaning of this ABNF:

      case-spec:
        ( "case" value ":")
        ( "case" value ":") *
        declaration “;"

So this leaves us with syntax errors in the spec, which are easy to repair, but clearly an annoyance.

JFYI.

Grüße, Carsten


> Begin forwarded message:
> 
> From: "Kretschmer, Andreas" <andreas.kretschmer@siemens.com>
> Subject: [CFRG] XDR in RFC8391
> Date: 2020-12-02 at 10:42:33 CET
> To: "cfrg@irtf.org" <cfrg@irtf.org>
> Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/LKMzLHjwVZQoobrObWUyhOUs4ds>
> Message-Id: <VI1PR10MB22850F4780CA2E97A7EA18F795F30@VI1PR10MB2285.EURPRD10.PROD.OUTLOOK.COM>
> 
> Hello,
> 
> I tried to use the XDR definitions given in RFC8391 Appendix A,B,C for generating a parser skeleton. Unfortunately I found some parts of the XDR definitions not compliant to the referred RFC4506:
> 
> - some Identifiers contain "/" and "-", RFC4506 allows only letter, digits and underbars
> - some enum bodies end with  ",}", RFC4506 requests "}" here
> - some union definitions have incomplete declarations in the case-spec, e.g. the union xmss_ots_signature refers to the wotsp-sha2_256 without giving a type.
> 
> Now my questions:
> 
> - Is there a fixed formal correct version of the  RFC8391 XDR definitions available?
> -  Whats the binary representations of an union holding incomplete  declarations?
> 
> Could somebody please give me a  hint or a pointer to the answers?
> 
> Regards,
> Andreas
> 
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg