Re: [ire] CSV and RFC4180

["Gould, James" <[e-mail]>]

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
Principal Software Engineer
[e-mail]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com







On 12/13/12 1:26 PM, "Gustavo Lozano" <[e-mail]> wrote:

>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
>>
>