Subject: [ire] CSV and RFC4180

From: Gustavo Lozano <[email-masked]>
Date: Thu, 13 Dec 2012 10:00:11 -0800

Colleagues,

I find the proposal of Comma-Separated Values (CSV) Objects Mapping
interesting and I think that both approaches CSV or XML for escrow data
have its advantages and disadvantages.

The only RFC related to CSV that I have found is RFC4180.

This text from RFC4180 concerns me:
TEXTDATA =  %x20-21 / %x23-2B / %x2D-7E

The escrow deposit will contain non US-ASCII data.

How can we be sure that the libraries/database tools used to implement the
export/import of CSV will adequately work with non US-ASCII data? There
are different platforms and architectures used by different players
(EBEROs, registry operators and data escrow agents) that will be upgraded
and will evolve during time.

In this regard I feel more confortable with XML because Unicode support
have been present since the beginning.

Thoughts?

Regards,
Gustavo Lozano

---

From: "Gould, James" <[email-masked]>
Date: Thu, 13 Dec 2012 18:04:34 +0000

Gustavo,

I don't believe that the file encoding is the key determinate of the file
format decision.  The CSV draft includes an encoding attribute with the
default of UTF-8.  It's up to the producer and consumer to support the
appropriate encoding of the data in any case whether we're talking about
XML as the file format or CSV.  I don't believe we would have any issue
producing or consuming UTF-8 encoded CSV files.

-- 

JG

James Gould
Principal Software Engineer
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 12/13/12 1:00 PM, "Gustavo Lozano" <[email-masked]> wrote:

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

---

From: Gustavo Lozano <[email-masked]>
Date: Thu, 13 Dec 2012 10:26:56 -0800

James,

I understand that we can produce text files encoded in UTF-8.

My concern is the TEXTDATA ABNF grammar defined in RFC4180: %x20-21 /
%x23-2B / %x2D-7E, which support a subset of US-ASCII extended only.

After pre delegation testing, ICANN will have evidence that the escrow
deposit file is correct, but this is only a snapshot in time. Registries
platforms are updated, RDBMS are updated, libraries are updated and in
general all the components of the SRS evolve during time. My concern is to
find in the future that the escrow deposit file of a registry operator is
corrupted because some library is now following the ABNF grammar in
RFC4180 or other validation rules. The same applies to the EBERO system.

XML being a well defined standard make more comfortable in this regard.

Regards,

Gustavo Lozano

---

From: "Gould, James" <[email-masked]>
Date: Thu, 13 Dec 2012 18:32:28 +0000

Gustavo,

Doesn't it state in RFC 4180 the following?

  Common usage of CSV is US-ASCII, but other character sets defined
      by IANA for the "text" tree may be used in conjunction with the
      "charset" parameter.

It does not preclude the use of UTF-8 or any other character set
(http://www.iana.org/assignments/character-sets/character-sets.xml), so we
should be good.

-- 

JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

---

From: Francisco Obispo <[email-masked]>
Date: Thu, 13 Dec 2012 10:35:24 -0800

One of the things I was thinking, is that the escrow dump is sort of like a ship's manifest, it needs to be as internationally 'readable' as possible, so that any port in the world can parse it.

Loading and unloading on the database should be secondary to all of this, we should be focusing on portability and recoverability.

Francisco

>> producing or consuming UTF-8 encoded CSV files.

Francisco Obispo 
Director of Applications and Services - ISC
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: Gustavo Lozano <[email-masked]>
Date: Thu, 13 Dec 2012 11:03:46 -0800

James,

The encoding of the file could be UTF-8, but my reading of the ABNF
grammar (Section 2 of RFC4180) is that the the code point repertory is
limited to %x20-21 / %x23-2B / %x2D-7E.

I have created a text file with non us-ascii code points, fields separated
by "," in my computer and I saved this file as UTF-8. I opened the file
with different applications without problem , but I am not sure that this
file can be considered CSV format compliant.

I am not trying to be picky here, the escrow deposit is a fundamental
piece of the registry transition process and RFC 4180 made me feel that
CSV is not as well as defined as XML.

Regards,

Gustavo

On 12/13/12 10:32 AM, "Gould, James" <[email-masked]> wrote:

>  Common usage of CSV
>is US-ASCII, but other character sets defined
>      by IANA for the "text"
>It does
>not preclude the use of UTF-8 or any other character
>set
>12061 Bluemont
>Way
>On 12/13/12 1:26 PM, "Gustavo
>Lozano" <[email-masked]> wrote:
>
>>James,
>>
>>I understand that we
>>On
>12/13/12 10:04 AM, "Gould, James" <[email-masked]>
>wrote:
>>
>>>Gustavo,
>>>
>>>12061 Bluemont
>Way
>>>On 12/13/12
>1:00 PM, "Gustavo Lozano" <[email-masked]>
>wrote:
>>>
>>>>Colleagues,
>>>>
>>>>How can we be sure that the libraries/database tools used to
>implement
>>>>the
>>>>(EBEROs, registry operators and data escrow agents)
>that will be
>>>>upgraded
>>>>In this
>regard I feel more confortable with XML because Unicode support
>>>>have been
>>>>Gustavo
>Lozano
>>>>ire mailing
>list
>____
>___________________________________________
>ire mailing
>list
>[email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Thu, 13 Dec 2012 20:21:54 +0000

Gustavo,

The RFC does not restrict it to ASCII and the use of CSV is heavily used in the industry for data export and import, so I don't believe there is an inherent advantage in the use of XML in supporting non-ASII data.

JG

James F. Gould
Principal Engineer
Verisign

[email-masked]