Re: [ire] CSV and RFC4180

[Gustavo Lozano <[e-mail]>]

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

On 12/13/12 10:04 AM, "Gould, James" <[e-mail]> wrote:

>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
>[e-mail]
> 
>703-948-3271 (Office)
>12061 Bluemont Way
>Reston, VA 20190
>VerisignInc.com
>
>
>
>
>
>
>
>On 12/13/12 1:00 PM, "Gustavo Lozano" <[e-mail]> wrote:
>
>>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
>>
>>_______________________________________________
>>ire mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ire
>