Subject: Re: [art] Updates to RFC4180 - CSV

From: Stian Soiland-Reyes <[email-masked]>
Date: Thu, 1 Apr 2021 09:45:37 +0000

Thank you Yakov for this suggested update.

As you pointed out in GitHub https://github.com/nightwatchcybersecurity/rfc4180-bis/issues/24 , RFC7111 is relevant, and it should be referenced from here for the fragment identifier part of the MIME Type Registration. 

Have you got any suggestions for profiles for CSV files? 

This RFC gives a narrow, precise definition for one way to make CSVs, which is very useful ; but we know there are multiple lower-case "csv" files, which may use different separators for instance. See Python's CSV module's list of CSV dialects and options https://docs.python.org/3/library/csv.html#csv-fmt-params 

A webserver determining mime type using file extension has no way to know that the file is conforming to this RFC or not, but may still want to serve it as text/csv instead of application/octet-stream as it's likely to be understood by more permissive CSV parsers.

On the other hand, a server generating a conforming CSV may want to indicate this, perhaps as:

Content-Type: text/csv; profile="https://www.rfc-editor.org/rfc/rfcTODO#ABNF"

(using the new RFC number of course)

In 2.1.3 you still add one variation allowing two effective rfc4180-bis dialects:

   3.  The first record in the file MAY be an optional header with the
       same format as normal records.

But previously in RFC4180 this presence was recordable with the optional "header" parameter. What is the argument of removing this? 

If desired, this change should be justified within the text.

I would argue today, following RFC6906, this precision would be better achieved with the optional "profile" parameter.

Content-Type: text/csv; profile="https://www.rfc-editor.org/rfc/rfcTODO#ABNF https://www.rfc-editor.org/rfc/rfcTODO#header"

Content-Type: text/csv; profile="https://www.rfc-editor.org/rfc/rfcTODO#ABNF https://www.rfc-editor.org/rfc/rfcTODO#noheader"

Note: "profile" is white-spaced, so here we indicate both that we have a header (or no header), in addition the intention to actually follow the ABNF of this RFC.  This allows someone to say they have a header even if they break the ABNF (or have not checked).

Unlocking the "profile" parameter would also allow third-parties to use it to indicate their own dialects, for instance https://docs.python.org/3/library/csv.html#csv.unix_dialect would be a perfectly valid profile.

-- 
Stian Soiland-Reyes, The University of Manchester
https://www.esciencelab.org.uk/
https://orcid.org/0000-0001-9842-9718
    Please note that I may work flexibly – whilst it suits me to email now, 
    I do not expect a response or action outside of your own working hours.

On 2021-03-26, 21:38, "art on behalf of Yakov Shafranovich" <[email-masked] on behalf of [email-masked]> wrote:

    On Fri, Mar 26, 2021 at 12:51 PM Julian Reschke <[email-masked]> wrote:
    >
    > Am 26.03.2021 um 17:19 schrieb Yakov Shafranovich:
    > > Hi,
    > >
    > > Since this RFC was published in 2005, there have been multiple
    > > suggestions and recommendations for updates. After being prompted by
    > > Oliver Siegmar, and talking to Barry Lieba, I have been working on a
    > > new draft with Oliver's help and just published the -00 version:
    > > https://tools.ietf.org/html/draft-shafranovich-rfc4180-bis-00
    > >
    > > There is also a GitHub repo here:
    > > https://github.com/nightwatchcybersecurity/rfc4180-bis
    > >
    > > Comments and suggestions are welcome.
    > >
    > > Thanks
    > > ...
    >
    > You may want to check <https://www.w3.org/2013/csvw/wiki/Main_Page> for
    > potential overlap...
    >

    Thank you, I was actually a participant in that W3C effort. The intent
    of that WG was much bigger than my RFC and draft - they wanted to come
    up with a metadata format to describe CSV files. My draft is somewhat
    more limited to the CSV format itself and its associated MIME type.

    Yakov

    _______________________________________________
    art mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/art