Re: [ire] CSV and RFC4180

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

On Dec 13, 2012, at 10:26 AM, Gustavo Lozano <gustavo.lozano@icann.org> 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" <JGould@verisign.com> 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
>> jgould@verisign.com
>> 
>> 703-948-3271 (Office)
>> 12061 Bluemont Way
>> Reston, VA 20190
>> VerisignInc.com
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On 12/13/12 1:00 PM, "Gustavo Lozano" <gustavo.lozano@icann.org> 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
>>> ire@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ire
>> 
> 
> _______________________________________________
> ire mailing list
> ire@ietf.org
> https://www.ietf.org/mailman/listinfo/ire

Francisco Obispo 
Director of Applications and Services - ISC
email: fobispo@isc.org
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE