[CFRG] Re: Where should test vectors live?

[Björn Haase <[e-mail]>]

Hi Carsten,

I think we both agree. 

>I was mainly trying to point out that we do have some means to include sourcecode-like snippets in RFCs *when that is the right thing to do*.
>You may have other reasons not to want that, but the technicalities aren’t those.

Yes. My issue was actually primarily on not how to integrate long lines in the RFC. I was mainly concerned with how to make things as easy and convenient as possible for an actual developer who would like to have access to the test vectors in binary-readable form.

IIUC 8792 includes description on what you could do for unwrapping long lines from an RFC and gives you also a bash script that helps you  if you are able to setup an execution environment for the bash. I did not find off-the-shelf tools for decoding that don't rely on the specific bash script. 
On my windows office PC for instance I will not be easily having a bash. Also I expect difficulties in case that a user actually gets a .pdf version of the RFC and wants to extract the test vectors.

IMO, the advantage of using plain BASE64 might be that a user that wants to use test vectors merely requires an ASCII text editor (for fetching the base64 block) and the base64-decoder tool of his choice (which might readily be a java-script online Base64 decoder) for getting the strings for the JSON file.

So when considering convenience for the end-user, base64 might make things easier.?!

Also I think that there might actually be two independent groups of users which are interested in test vectors. Let's call them "Daniel Debugger" and "Urs Unittester".

a) Daniel runs test code and wants to compare the RAM content in variables seen in the software debugging environment with the text document. I think, Daniel wants a human-readable base16 encoded test vector as string.

b) Urs sets up unit test environments for testing library code. I think that Urs wants to best have a JSON-encoded binary interpretable version of the test vectors.


I think, that we should be try our best at CFRG to make both, Daniel and Urs happy.

For getting things pushed forward, my personal suggestion for answering the question " Where should test vectors live?" would be the following:

Suggested answer to the question "where should test vectors for CFRG drafts live?":
"
1.) The test vectors SHALL live in the RFC and/or ID document
2.) The test vectors should be redundantly included in two forms. Firstly test vectors SHALL be made available in form of a textual "human-readable" format. Secondly for all human-readable textual test vectors there SHOULD BE a redundant base64 encoding that decodes to a file and provides the test vectors in a machine-readable format. It is RECOMMENDED to use JSON as portable machine-readable format.
"

What is Your opinion on that suggestion?

Yours,

Björn.




Mit freundlichen Grüßen | Best Regards 

Dr. Björn Haase 


Senior Expert Electronics | TGREH Electronics Hardware

Endress+Hauser Liquid Analysis

Endress+Hauser Conducta GmbH+Co. KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: [phone]
[e-mail] |  www.ehla.endress.com 



Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

 
Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

 

Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.